Java Web Start : Java Glossary

Starting in JDK (Java Development Kit) 1.8.0_131, 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 (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 (Java Runtime Environment) 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 (Uniform Resource Locator) href link in your browser like this, or type it in on the address line:
   http://mindprod.com/webstart/esper.jnlp
2. To launch from the command line:
3. Unfortunately, this third method only works in older JDKs (Java Development Kits). 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://localhost/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. To this day I have not figured out what the matter was. I have tried a complete reinstall without success. The problem when away with a complete reinstall of the OS (Operating System) and Java.
• Java Web Start now ignores the properties in the JNLP file, unless you put the JNLP file inside the jar naming it JNLP_INF/APPLICATION.JNLP and signing the entire jar. (Note that is JNLP_INF not JNLP-INF.) I you have to launch with an external copy of the JNLP file with a different name. You cannot link to the jar or use some sort of OBJECT tag. Oracle provides some JavaScript called deployJava for generating a launch button. There may be a way in there.
• 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\jre1.8.0_131\ \bin\javaws.exe

  With Java version 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\jre1.8.0_131\\javaws\javaws.jar in the JRE and in J:\Program Files\java\jdk1.8.0_131\\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.8.0_131\\sample\jnlp\servlet\jnlp.jar " C:\Program Files\java\jre1.8.0_131\ \lib\ext"
  copy J:\Program Files\java\jdk1.8.0_131\\sample\jnlp\servlet\jnlp.jar " J:\Program Files\java\jdk1.8.0_131\ \jre\lib\ext\
  or set the classpath environment variable like this:
  SET CLASSPATH=.;C:\;E:\;J:\Program Files\java\jdk1.8.0_131\\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 DLL (Dynamic Link Library) s for JNI (Java Native Interface) 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.
• Oracle’s Java 1.8 documentation on : IE Bug
  Your server must tell the browser to cache the JNLP file. If it does not, IE (Internet Explorer) 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 (Application Programming Interface).

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 (Hypertext Transfer Protocol) server. Without a special server, files are downloaded with ordinary HTTP with is not restartable if the download aborts. Oracle 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 Oracle’s specific implementation of JNLP. There are other JNLP projects: Juniper and OpenJNLP on SourceForge.

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

JNLP leaves this unspecified, but Oracle’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.

You can write a class whose main method is invoked on install. You declare it as such in your JNLP file with <installer-desc main-class=com.mindprod.xxxx.Installer />. Normally it uses methods of javax.jnlp.DownloadService; and javax.jnlp. ServiceManager; It will be called with a the String install.

Java WebStart is supposed to call your Install class main method on uninstall as well, but with parameter uninstall, however, nobody has been able to get it to work.

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\jre1.8.0_131\ \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\Oracle\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

If you type javaws.exe myapp.jnlp and launch your app, there is a preferences section where you can turn on a java console and console logging to a file. You need the file because the console disappears the instant the app terminates.

What I do to debug is strip out all the JNLP-ness and replace the logic with System.getEnv or hard code to turn the program into an ordinary desktop app. Then I debug it. Then I turn the JNLP code back on. There surely is a better way, but I have not yet found it. In a simple case, you can simulate all the JNLP properties in the JNLP file with -D options on the command line. A JNLP property like this:
  <property name="KEEP_ZIPS" value="false" />
can be simulated with system properties on the vm command line options like this:
  -DKEEP_ZIPS=false
The problem is in may work fine from the command line, but not with Java Web Start and you have no idea what the problem is.

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 Java version 1.6 with Vista, it caches your Java Web Start files in C:\Users\user\AppData\LocalLow\Oracle\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 (Application Programming Interfaces). 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 hideously) 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 (Java Virtual Machine) 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 (Local Area Network) 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, Oracle 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 (Java Runtime Environments) 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.
• no access to user 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\user\Application\Data\Oracle\Java\Deployment\ and delete files associated with the recalcitrant application.
• If that does not work go into C:\Documents and Settings\user\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 (Compact Disc)

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 essential problem is you don’t know the drive letter of the CD drive that will be used to read the JNLP file and you have to hard code that letter into the JNLP file ahead of time.

The problem was, my program did not know where javaws.exe was installed so it could not automatically start it up. Prior to  Java version 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 and W98 and cmd.exe for NT, W2K, XP, W2003, Vista, W2008, W7-32, W7-64, W8-32, W8-64, W2012, W10-32 and W10-64. 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.

There are new magic variables in JNLP that I have not deciphers. They may allow a simpler solution.

Others have tried more sophisticated approaches. The VAMP (Venus Application Publisher) people came up with a number of ingenious Rube Goldberg solutions. It is not their fault. Oracle 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 Oracle 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 Java version 1.5 or later, Oracle 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 (Compact Discs) 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 × 255 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.

Uninstalling

• Deleting the app’s icon with right click delete gets it out of mind, but leaves all the files intact.
• In Windows Vista you can use Start ⇒ Control Panel ⇒ Programs and Features ⇒ right click on app ⇒ uninstall.
• Alternatively, at the command prompt type javaws -viewer The right click the app and select delete.
• In the Java Control panel in the Windows control panel, click the General tab. In the Temporary Internet Files section, click the View button. The Java Cache Viewer dialog box will appear. In the Show: combo box, select Applications and then select the app you wish to uninstall in the application list. Right click delete.
• In Ubuntu Linux, for Java software installed from Ubuntu Linux software repository as described in System Requirements, the Java Control Panel is available in the Preferences submenu of the main System menu.

If the above measures all fail, manually uninstall with:

1. At the command prompt type javaws -viewer The right click the app and select delete.
2. Use Ace Utilities To remove the entry in the control panel.
3. Look in C:\Users\user\AppData\LocalLow\Oracle\Java\Deployment\cache\6.0\ and wipe out the files associated with your app. Unfortunately the file names will bear no resemblance to your app name. You will have to examine file contents.
4. Delete the desktop icon and menu items with right click delete.

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

Book referral for Java Deployment with JNLP and Web Start

	recommend book⇒Java Deployment with JNLP and Web Start
	by	Mauro Marinilli	978-0-672-32182-5	paperback
	publisher	Sams
	published	2001-09-29
470 pages.
Online bookstores carrying Java Deployment with JNLP and Web Start abe books anz abe books.ca abe books.de amazon.ca amazon.de Chapters Indigo amazon.es Chapters Indigo eBooks iberlibro.com abe books.com abe books.fr amazon.com amazon.fr Barnes & Noble abe books.it Nook at Barnes & Noble amazon.it Kobo junglee.com Google play abe books.co.uk O’Reilly Safari amazon.co.uk Powells other stores
Greyed out stores probably do not have the item in stock. Try looking for it with a bookfinder.

Learning More

The Java Web Start runtime comes bundled with the JDK or JRE, includes Application Developer’s Guide, Download Servlet Guide, JNLP. API Documentation, jardiff tool, jnlp-servlet.jar file and the jnlp.jar file.

API

Guides

Spec

Tutorial

Older Material