Java Web Start : Java Glossary

Starting in 1.6.9_10 beta, Java Web Start can also distribute Applets. They run in an independent window that can be dragged and resized. The Applet code is not downloaded each time, but only when the code changes.

Sometimes called JWS — Java Web Start (or improperly JAWS) — Java Web Start. They automatically install and hook themselves up to the Java runtime. All you have to do is click an icon with your browser to use them. Note it is called Web Start, two words, not WebStart. Don’t confuse Java Web Start with Solaris Web Start which is an installer for Solaris platform-specific software. Java Web Start makes it easy for users to install Java apps once they have a web start enabled browser, or the web start app installed.

You can think of Java Web Start apps as ordinary apps plus five main extra features:

• one click install.
• optional custom installer code.
• automatic update.
• a mechanism to reserve you some free disk space without having to pester the user for a unique name for it.
• a mechanism to select the best fit JRE javaw.exe.

Trying out Java Web Start

Installing A Java Web Start Program

There are three ways to install a Java Web Start Application:

1. Click on a jnlp URL href link in your browser like this, or type it in on the address line:
   http://mindprod.com/webstart/esper.jnlp
2. To install or launch without a browser:

   rem launching javaws from the command line:
   javaws http://mindprod.com/webstart/setclock.jnlp
   
   rem launching with additional debug information
   javaws -verbose http://mindprod.com/webstart/setclock.jnlp
   
   rem launching from a local jnlp file on hard disk
   javaws file:///E:/mindprod/webstart/esper.jnlp
   
   rem learning the javaws.exe command line options
   javaws -help

3. Unfortunately, this third method only works in older JDKs. Start Java Web Start, i.e. javaws.exe, then type or paste in the name of a jnlp reference such as http://mindprod.com/webstart/esper.jnlp into the locate box. For local files you will need the equivalent url, e.g. file://localhost/E:/mindprod/webstart/esper.jnlp or the shorter form: file:///E:/mindprod/webstart/esper.jnlp. Unfortunately starting with JDK 1.5, the javaws.exe no longer has a locate box, so this method is no longer possible.

Opera and Java Web Start

What Is a Java Web Start Application?

Some of the terms for Java web Start applications are:

• rich clients
• rich Internet apps
• rich desktop apps
• weblets, though Gerald Bauer, a Java Web Start developer, told me this term was not correct, because it improperly implied that the applications were necessarily small.

Gotchas

• On 2008-02-22 Java Web Start decided to stop working when I ran my apps from the desktop icons, but it would work from within a browser. It claimed I did not have Java 1.6 installed. I have not figured out what the matter is. I have tried a complete reinstall without success.
• If you make a syntax error in your JNLP file, it can get stuck in cache. JWS refuses to replace it with the new one posted on the website. The only way around this bug I could find was to use javaws -uninstall to uninstall all JWS apps.
• Starting with JDK 1.4.2, Java Web Start gets installed many times. This provides potential for using out of date copies. Here are places I have seen it install:
  • J:\Program Files\java\jdkXXX\jre\javaws\Java Web Start 1.2.0_03
  • J:\Program Files\java\jdkXXX\jre\javaws\
  • C:\Program Files\java\jreXXX\javaws
  • C:\Program Files\Java Web Start
  Things seem to have settled down, so if you are using the latest Java, you should count on the version at: C:\Program Files\java\jre6\bin\javaws.exe

  With Java 1.5 the Control Panel seems to handle fairly well which Java is the active one. Prior to that it was foolhardy to have more than one JDK or JRE installed. You would forever be getting bits of the wrong JDK/JRE. It still happens with browsers in 1.5.

• Contrary to the documentation, the class files you need, e.g. javax.jnlp.*, com.sun.javaws.* and com.sun.jnlp.* live in C:\Program Files\java\jre6\javaws\javaws.jar in the JRE and in J:\Program Files\java\jdk1.6.0_10\jre\javaws\javaws.jar in the JDK. This file is automatically installed when you install the JRE or JDK.
• If you use any of the JNLP classes, e.g. javax.jnlp. DownloadService or javax.jnlp. ServiceManager, you will need the jnlp.jar in your ext directories or on your classpath if you develop (i.e. compile) JWS applications, but not if you merely run them. You have to manually add the jar to your classpath to compile. Here is how to copy the jnlp.jar to the ext dirs.
  copy "J:\Program Files\java\jdk1.6.0_10\sample\jnlp\servlet\jnlp.jar" "C:\Program Files\java\jre6\lib\ext"
  copy "J:\Program Files\java\jdk1.6.0_10\sample\jnlp\servlet\jnlp.jar" "J:\Program Files\java\jdk1.6.0_10\jre\lib\ext"
  or set the classpath environment variable like this:
  SET CLASSPATH=.;C:\;E:\;J:\Program Files\java\jdk1.6.0_10\sample\jnlp\servlet\jnlp.jar
  The catch is, you must have no quotes!. If you screw up the quotes, you don’t get an error message, it just can’t find the classes. Note that you if you use -classpath on the command line, then the quote rules are different. See classpath.
• The Web Start install does not tweak the Opera browser to understand jnlp files. Neither does the Opera installer handle setting up the association. You must do that manually with the procedure described above.
• If you are a developer broadcasting JWS programs, you must also talk to the ISP who hosts your website to set up association from extension to MIME type for .jnlp and any of the other Java file types you use such as .class, .java, .jar, .jardiff and .ser . See MIME for details.
• Web Start transfers only jar files. It is up to the application to unpack them if necessary. However, there is the nativelib tag that lets you specify a jar full of DLLs for JNI native code that it will unpack automatically. Java Web Start does not deal well with updating large files. If so much as one comma in them changes, it transfers the entire file. It does have a feature called jardiffs for sending a jar file of only members that have changed. It needs some automation to make it more practical to use. See the Automatic File Update and Delta Creator student project for a solution to these problems.
• Sun’s JDK Technote Guide on IE Bug : available:

  • on the web at java.sun.com
  • in the current JDK 1.6.0_10 on your local Windows J: drive.
  Your server must tell the browser to cache the JNLP file. If it does not, IE will not save it to disk for javaws.exe to use. Similar problems occur if IE has caching turned off or a full cache.

JNLP

Applets

<applet-desc
    documentBase="http://mindprod.com/applets"
    name="Wassup"
    main-class="com.mindprod.wassup.Wassup"
    width="540"
    height="310">
  <param name="milkshake" value="strawberry" />
  <param name="fruit" value="peach" />
</applet-desc>

Features

There are a number of services your Web Start application can use. DownloadService lets you check what is in the cache, and remove items from the cache. FileSaveService lets even unsigned applications write to hard disk though the somewhat clumsy FileSaveService API.

Web Start has features for keeping track of various versions of files and automatically ensuring the users have the most up-to-date files. Unfortunately, the version-based protocol requires special support on the Web server. This support can be provided using servlets, CGI-scripts, or by similar means. You can’t pull it off simply by changing the names of the various jar files you upload to a standard http server. Without a special server, files are downloaded with ordinary HTTP with is not restartable if the download aborts. Sun provides a reference Servlet in the download that implements the JNLP protocol that you could run your server. I have no experience with it.

Web Start is Sun’s specific implementation of JNLP. There are other JNLP projects: Juniper and OpenJNLP on SourceForge. Fontanus Zydego has an implementation similar to JNLP.

I am not sure which of the above projects are client/server or both.

JNLP leaves this unspecified, but Sun’s Java Web Start reference implementation downloads and applies any updates only after you run a program. This unexpected convention has three advantages:

1. It avoids making the user wait to do useful work. Most of the time the update is not critical.
2. It only bothers refreshing programs you actually are actively using.
3. It does not require unattended access to the Internet to fetch downloads, which would happen if updates were scheduled each evening on all apps, LiveUpdate style.

The disadvantage is if a customer complains about a bug and you fix it, they won’t see the fix the next time they run the program, only the time after that.

The really nice thing about Java Web Start is that it does not put many restrictions on how you code. It is very easy to take and ordinary app or Applet and tack on a JNLP file to make it ready for Java Web Start. You don’t need two have different code bases, one for standalone and one for JWS. This also protects you in case some day JWS goes the way of all flesh. You could then easily convert your JWS back to pure standalone with an optional installer. You can use JWS as if it were purely an easy-to-use installer for ordinary apps, with automatic updating.

Shortcuts

<!-- hints for setting up shortcuts -->
<!-- Prefer a shortcut for online operation -->
<shortcut online="true">
  <!-- create desktop shortcut -->
  <desktop/>
  <!-- create menu item for this app under the major heading Esperanto -->
  <menu submenu="Esperanto"/>
</shortcut>

If you want JWS to recreate menu and/or desktop shortcuts, delete both the menu item and the desktop icon, then run javaws -viewer on the command line then click the  button to create the shortcuts. If either one exists, javaws.exe won’t create the other. It also might not create them where you were expecting, so look around.

To bypass problems, you can also create your own shortcuts and menu items manually. To do that, right click on the desktop ⇒ new ⇒ shortcut. Then select the JRE javaws.exe as the launch program e.g. "C:\Program Files\java\jre6\bin\javaws.exe". Then right click the icon ⇒ properties and add the name of the URL after the name of the javaws.exe launch program e.g. "http://mindprod.com/webstart/affirm.jnlp". Don’t forget the quotes. You can select a better icon, perhaps by looking in places like: C:\Documents and Settings\Administrator.ROEDY\Application Data\Sun\Java\Deployment\cache\javaws\http\Dwww.mindprod.com\P80\DMimages\RB affirm.gif.ico

Then you can right click drag ⇒ copy that desktop icon wherever you want onto your menu.

Debugging

Always have your app display the version, and change the version for every compile. Otherwise, you could very easily be debugging an old version in cache and not know it. Redating the JNLP files seems to help flush caches faster.

Check the list of running tasks. Sometimes you will see failed java incarnations hanging on. They need to be manually killed or you need to reboot to get rid of them. They can interfere with your debugging.

Especially during launch failure, check all the tabs of the dialog box for clues to the problem. There is much more information than first meets the eye in the general tab.

Where are the Files?

In JDK 1.6 with Vista, it caches your Java Web Start files in C:\Users\ userid\AppData\LocalLow\Sun\Java\Deployment\cache\6.0 assigning them names completely unrelated to the application.

You can pass configuring information to your application two ways via the resources/properties section of the JNLP file and by putting information in the jars to be got at with getResource.

Persistence

Unsigned applications have to use the Mickey Mouse PersistenceService APIs. Signed applications could use the registry-based Preferences class.

Why not just use regular files that way any sane programmer would? The problem is finding them again the next time you execute. There is no data directory naturally associated with the application. Unless you put them in an absolute location, you at least need some way of recalling the name of the directory where all the data are. You can use the system properties user.home and java.home as ways to locate files. You can ask the user, as part of the install or as you run. You can also use the javax.jnlp. DownloadService and javax.jnlp. ServiceManager services to find you some uniquely (and hideeously) named disk space.

Detecting Java Web Start

You can test your Java Web Start installation with some of

What’s Right With Java Web Start

• Java Web Start is the easiest to use installer both for developer and client.
• Clients can try out new apps with just a single click.
• Java Web Start automatically applies updates.
• Initial downloads are compact.
• Java Web Start puts almost no restrictions on how you code your application. You can add it later, and take it off later without affecting anything else.

What’s Wrong With Java Web Start

• Java Web Start applications are painfully slow to start. The monitor loads a fresh JVM for itself and for each application. Applications always check on the web for updates, downloading and processing an entire new JNLP file, rather than just checking its date. However, if it takes 80 seconds or so to check for a new version, it means you are likely having trouble with a proxy server. Start javaws.exe and click edit ⇒ Preferences ⇒ Network Settings ⇒ Direct. You don’t want JWS trying to use the Google Accelerator proxy. Also check in IE, click tools ⇒ Internet Options ⇒ Connections ⇒ LAN Settings and make sure all is as you expect.
• Updates take just about as long to download as the original application. There has been almost no cleverness applied to make the updates compact.
• It requires custom code running on the ISP to properly serve the jardiff files or to use the coming pack200 hyper compression.
• It has not changed much since its initial release. It may be yet another orphaned product. It does not deserve to be. However, Sun has released a new beta 1.2 after a year or so of nothing happening, and it has been integrated into the JRE, so we’ll see if it is picking up steam again. There are some major problems they have ignored, such as the certificate OK hiding behind the splash screen, and requiring ok for every jar separately. Even if it is orphaned nothing to terrible will happen. Unless you write unsigned JWS apps and use the JWS sandbox, your JWS apps will run fine standalone.
• It requires special configuring of the JNLP MIME type both at the ISP and in the client’s browser. Neither of these are under the developer’s direct control.
• If you have an urgent update, you can’t force it to be installed before the app is ever run again.
• It needs a rigid scheme to assign hard disk space on the client’s machine that has the following properties:
  • The names of the directories assigned must avoid name clashes with other vendors. They should incorporate the main package name of the application.
  • The names must be meaningful to the end user. They should be something he can remember, find and type when he needs to find files with desktop tools.
  • The scheme must provide a place both for per-user and per-application files.
  • A program should work on any platform without modification to deal with finding its files.

Sandbox

If your JWS app is unsigned it must conform to the following restrictions:

• No access to local disk.
• All your jars must be downloaded from the same host. Note, however, that you can download extensions and JREs from any host as long as they are signed and trusted.
• Network connections are allowed only to host from which your jars were downloaded. No talking to strangers.
• No security manager can be installed.
• No native libraries (not even in extensions).
• Limited access to system properties. The application has read/write access to all system properties defined in the jnlp file, as well as read-only access to the same set of properties as Applets. See Wassup for a list of safe and restricted system properties.

Signing

All jars must be signed with the same certificate. This means you must unpack and resign jars built by somebody else. However, Rogan Dawes the author of WebScarab pointed out a way around that restriction. He discovered that if you have multiple JNLP files, all jars mentioned by each JNLP file must be signed with the same certificate, but different JNLP files can be signed with different certificates. Your master JNLP file includes an auxiliary JNLP file (which references jars signed with a different certificate) by inserting a line like this in the <resources> section:

Recovering From Java Web Start Failures

• If Java Web Start behaves strangely, try killing any javaw.exe, java.exe and javaws.exe tasks.
• If that does not work, try rebooting.
• If that does not work try uninstalling and reinstalling the faulty app.
• If that does not work, try clearing the cache with File ⇒ Preferences ⇒ Advanced ⇒ Clear Folder. This will uninstall all your apps. Then reinstall.
• If that does not work go into C:\Documents And Settings\Administrator\Application Data\Sun\Java\Deployment\ and delete files associated with the recalcitrant application.
• If that does not work go into C:\Documents And Settings\Administrator\Data and delete files associated with the recalcitrant application.
• If that does not work, uninstall the JRE and reinstall it.

Distributing Java Web Start Apps on CD

This was a bit confusing for the user, so I wrote a little Windows-only C program to figure out which drive letter is the current drive and then automatically select the correct JNLP file. My kicker C program can’t simply generate a custom JNLP file on the fly since the result has to be on the unwriteable CD along with the jar.

The problem was, my program did not know where javaws.exe was installed so it could not automatically start it up. Prior to JDK 1.5, Javaws.exe does not put itself on the path, and does not put any kicker to itself on the path the way it does for java.exe. So I had to spawn a command processor that understood the *.jnlp extension association. This is command.com for W95/W98 and cmd.exe for NT/W2K/XP/W2K3/Vista. I then added an autorun.inf to kick the whole process off automatically. The main problem with this approach other than that it requires 26 generated JNLP files, is that it works only on Windows. Further, it presumes the association between *.jnlp and javaws.exe is functioning.

Here is the C++ source code for Setup.exe.

Others have tried more sophisticated approaches. The Vamp ( Venus Application Publisher) people have come up with a number of ingenious Rube Goldberg solutions. It is not their fault. Sun has made this needlessly difficult. Unfortunately, the Vampqh download links are now dead to clio, Jes, Celia and Pam.

The proper solution to the CD install problem is for Sun to support codebase="cd". It has to be possible for Apps to redistribute themselves in the field on CD to get past firewalls, and carrying data with them. End users can’t tolerate complicated procedures just to move a downloaded JWS app to CD. Instead of my suggested codebase="CD" parameter, in JDK 1.5+, Sun implemented this:

javaws -import -codebase file:///R:/appa R:/appa/jnlp/app.jnlp

From the end user’s point of view, all he should have to do to is insert a CD containing a JWS install or update in a CD drive, and double click the icon representing the JNLP file. This should work for any platform, requiring only that a JRE be preinstalled.

For Windows an autorun.inf file should do it normal thing to start the launch, as should the equivalent feature for any other OS.

Alternatively, for a mouseless install, the user should simply have to run javaws R: to start any CD install. He should not even have to spell out the name of the JNLP file.

In a similar way, installing a JRE from CD should be equally painless, perhaps requiring the user to select an icon corresponding to his OS from the CD. Then it would check if an install or update were needed, and at the very least do a sanity check of the install to make sure it was intact and the registry was properly set up.

Then if I had my way, these CDs would be distributed in breakfast cereal boxes with a JWS game or two to install the latest Java on every home desktop ready for subsequent online JWS installs over even slow phone lines.

Passwords

Applets vs JWS vs Applications

Java Web Start Icon

I commissioned an artist from Aha-Soft to create an icon for Java Web Start. It looks like a winged coffee bean being launched by a spring. It comes in sizes from 16 × 16 to 256 × 256 in png, gif, ico and bmp formats. You may download the entire suite of sizes and formats and use it as you please for any purpose but military.

Summary

• Clients don’t have to download the app every time, only when it changes.
• Updates to the application are automatic. Even if the jnlp file does not change, if any of the jars change, JWS detects that and downloads the new version automatically. It also updates the desktop icons to the new images and text.
• You don’t get variable behaviour caused by bugs and obsolete software installed in various browsers.
• There is more free RAM without the browser there too.
• Java Web Start automatically checks for version compatibility.

Books

	recommend book⇒Java Deployment with JNLP and Web Start
		paperback
	ISBN13:	978-0-672-32182-5
	ISBN10:	0-672-32182-3
	publisher:	Sams
	published:	2001-09-29
	by:	Mauro Marinilli, Mauro Marinilli
470 pages.
abe books.co.uk abe books.ca amazon.co.uk amazon.ca abe books.de chapters.indigo.ca amazon.de abe books.com abe books.fr amazon.com amazon.fr barnes and noble.com abe books.it powells.com iberlibro.com abe books anz

Learning More