Comments - If I Were King: Making Java Web Start Stronger and Ready for Prime Time

Give away your perls of wisdom and let Sun know how to make Web Start stronger and ready for prime time. Send your items and comments to the lopica-talk mailinglist (Subscribe/Unsubscribe) and I will add them to the Web Start 2.0 wish list.

What: Web Start is missing a SocketService that works the same way the PersistenceService, PrintService, ClipboardService, etc. work.

Why: There is a clear need to interoperate with and leverage existing corporate services. Currently secure Java applications (unsigned) are unable to interoperate with existing corporate services solely because of a lack of a SocketService. Examples of Java's inability to interoperate: 1. Web Services (SOAP) 2. WebDAV 3. Access to financial systems (ACCPAC, QuickBooks, etc... which use TCP/XML to communicate)

- Mark Swanson

Lobby Sun and vote for Bug #4876235: [RFE] SocketService at Sun's Bug Parade

I'm currently strongly in favor of creating Web Start apps that do not enable all-permissions. I think it's better to use the Web Start services to read/write to disk, print, access the clipboard, etc. I wrote a small HTML document that explains the reasons.

- Mark Swanson

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

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.

- Suprit Chaudhary (http://www.eurologic.com )

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 (http://www.RadiSys.com )

Another feature that should be added (if its not already there) is:

1. API to launch the default browser on a machine and access the DOM tree.
2. Able to cache other resources (XML, properties, etc.) other than just jar files.

- Christopher Burkey (http://einnovation.com )

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 than 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 wrong jre/lib/ext directory.
• 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.
• The 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

The two things on my wish list are:

• ability to open a resource file as a JNLPRandomAccessFile. 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

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 bandwidth-constrained users.

A good forum for such discussion is a related RFE (bugid:4267080) .

- Joe Walp

Lobby Sun and vote for Bug #4267080: [RFE] custom JRE installer geared towards the clients at Sun's Bug Parade

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 users (yet).
• 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 downloaded.
• 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 )

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:

  java -cp jnlp.jar com.sun.jnlp.Main http://localhost/toto/test.jnlp

  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!)

- Jean-Baptiste Bugeaud (http://www.up2go.net )