ContactAre You Real? - Ich Spreche Deutsch
vampgetGrab Apps for Offline Consumption
FAQAnswer, Answers, Answers
InfoHire Me - Yes, I'm Available
Comments - If I Were King: Making Java Web Start Stronger and Ready for Prime Time
June, 12th, 2002 - Make the Command Line Work
Making the command line work is important for deployment of applications.
No command line makes me think I am working on a Mac 9. Web Start is cool
stuff but I am amazed how Web Start could have been be released without
providing the basic command line support. Or does Sun want us to use their
application manager only?
- Zahid Patel
May, 22nd, 2002 - Suprit Chaudhary
Web Start should not depend on browers for launching.
It should have a command line as well as a location text field like browers
have to launch the .jnlp file from Web Start itself.
It looks very bad just to launch .jnlp we need browser support.
December, 21st, 2001 - Nick Gusev
What if I have more than one host for the same app (mirrors,
etc.)? I don't want to have two (or more) instances of the sampe app.
Right now it is inevitable.
- Nick Gusev
August, 21st, 2001 - Christopher Burkey
Another feature that should be
added (if its not already there) is:
- API to launch the default browser on a machine and access the DOM
- Able to cache other resources (XML, properties, etc.) other than
just jar files.
August, 10th, 2001 - Mike Rarick
Here are the features I'd like to see added to Web Start:
- A flag in the JNLP file to limit more than one copy of the application from running at once.
I have implemented the socket technique in my application, but
this is extra overhead that wouldn't be needed if JNLP supported this.
It could also eliminate the need to sign applications that use sockets just for this purpose.
- Use the system's CLASSPATH. Some applications install ZIP or JAR files to directories other
jre/lib/ext and then add this to the CLASSPATH.
Web Start doesn't use the CLASSPATH and hence, cannot find these JAR files.
This can also be a problem if you have multiple JREs installed and the JAR file is in the
- Fix the dependent DLL problem. If you have multiple DLLs in a resource file that are dependent on each other,
only the first one is found. I think this is basically a PATH problem, similar to the CLASSPATH above.
- I need a way to communicate between the Java application launched by Web Start and the Web page that launched it.
Specifically, I want to close my application if the user navigates to a different page on my site.
- Give the user options to download updates. The current version automatically downloads updates immediately,
which is infinitely better than previous releases that had that quirky "download next time" feature.
Ideally, the user could choose to download now or later. For example, if I use a laptop connected to
the network at the office, I'd probably want the update immediately.
However, if I'm on the road and connected with a slow modem, I might not want to sit
through a 30 minute download for a minor update.
- Splash screen. Sun insists that they must show their splash screen to give the user a "consistent interface".
Hogwash-- I say it's pure marketing. If Microsoft
displayed their splash screen every time an application is launched from Windows, people would go through the roof!
My users could care less that Web Start is being used.
They just want the application launched when they click on the link.
The JNLP file should be able to specify a different splash screen, no splash
screen, or at the very least a way to add my icon and information to Sun's splash screen.
- HTTPS support. I've seen many requests for this on the Web Start forum.
Even though it may be slower, some people may not want to implement a second
non-SSL server just for Web Start files.
BasicService has a method
showDocument() that directs a browser on
the client to show the given URL. However, if your browser is already open,
it replaces the current page. An optional flag should be available to
force a new browser window. This is useful for viewing online help without the
user losing the current location in their browser.
- Mike Rarick
August, 7th, 2001 - Dale King - Wish List
The two things on my wish list are:
- ability to open a resource file as a
Jar files only give you sequential access to contents.
- ability to make a JNLP application a handler for specific mime types.
This will allow you to publish documents to your website and have them
open in the application when you click on them.
- Dale King
July, 25th, 2001 - Joe Walp
I'm soliciting comments on the feasability of using the
cache management of Web Start (bundled with the latest HotSpot
VM) to provide a minimal JRE installation and incremental
upgrades for multiple JRE versions. In other words, this
variant of Web Start would bootstrap the JRE installation and
maintain multiple partial JRE class libraries for
A good forum for such discussion is a related
- Joe Walp
July, 12th, 2001 - John Munsch -
While I support your petition in theory I don't in practice...
While I too think that Java Web Start is about the neatest thing since
sliced bread (which is why I used it for my own application, HotSheet)
I don't agree with many of the items you've picked to change.
The cache API is an excellent idea and I support that, but the command
line (?!?) and DLL sharing are not my highest priorities. Way, way above
that would be:
- A Mac OS X implementation. OpenJNLP is not a real substitute for Mac
- The ability to avoid the JIT for something that is used everyday.
It's not exactly "Just In Time" if it is doing the exact same work again that it
did yesterday and the day before. For that you really want it to just
compile the darn program and save it. Then dump the compile when new JARs are
- The ability to either launch a new browser or reuse an existing one
from the JNLP. Right now it always launches a new browser.
- Availability of all the JNLP functions for applications running
outside of Java Web Start so that applications can be written once and run on
platforms without Web Start (like AIX, for which I had to bundle additional code
to launch a browser).
- Some way to easily offer authentication/lockout/(whatever you want to
call it) so I can offer commercial applications through JNLP. I want to be
able to sell a program through JNLP but I don't want people to forever get
new upgrades. It would be nice if I could cut them off from new upgrades
after a period but they could still run the software and it wouldn't keep
checking for new versions for those users. As it stands today I'd have to change
the URL of my JNLP file or something to stop them (which would break users
who had paid to continue receiving upgrades).
So to my way of thinking the solution wouldn't be for me to have a list
of favorite items and try to get people to petition for that, it would be
to get everybody suggesting ideas on what is most important for the next
release. When we have a good set we vote on what is most important and
petition for that. Who knows, somebody might have much better
improvement ideas than either of us.
- John Munsch (http://www.johnmunsch.com
July, 12th, 2001 - Jean-Baptiste Bugeaud - Petition
About your petition i agree that there are lots of things that should be done:
prevent people from having to download 10times a xerces parser on each software, 5 times Java3D, ...etc!
This means that there should exist any official repository (not maintain directly by sun), where any valid java extension for all platform should be
stored! When requesting Java-Media extension for an application the JNLP client should go to the repository and get it, install it and run the application :)
The java extension ID should be some kind of URN ;-)
Another request is to authorize the socket connect to the server where the .jnlp file reside (no only where the .jar files are!) this would be quite
usfull if you will to delegate file transfer to any download provider!
put PNG as an official valid file format for JNLP icons as supported since Java2-1.2.2!
- add the
openca.org certificate as a valid root certificate! So developer may get free valid certificate and people may trust them :)
this is the most important: either enable the debug process of a JNLP application (ie: either activate the remote debug by passing a flag into the .jnlp, the poping the
password for remote access; or allow the
jnlp.jar to be directly added into a classpath such as:
or provide a foo implementation into the dev. kit of the JNLP services!
(none are yet feasible: this prevent any debug phase once using any JNLP service!)
java -cp jnlp.jar com.sun.jnlp.Main http://localhost/toto/test.jnlp