Java Web Start : Java Glossary


JWS: Java Web Start  Java Web Start
JWS (Java Web Start) is the official spelling, though you will he half a dozen variants. Oracle’s tool for installing Java applications and updates.

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.

Astoundingly, Oracle made a change to Java that deliberately broke existing applications in the name of increased security. Here are three ways to fix the problem:

  • Buy a real code-signing certificate and put a copy of your *.jnlp file inside the jar under the name. JNLP_INF/APPLICATION.JNLP before you sign the jar. You still need a freestanding copy to launch the app.
  • put your properties in a resource in the jar and read them with Properties.load instead of System.getProperties.
  • Run the app standalone. Put the properties as -D switches on the command line. Read them with System.getProperties.

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:

Tryout Debugging CD Installs
Installing a JWS Program Where are the Files? Passwords
Opera Persistence Applets vs JWS vs Applications
What Is JWS? Detecting Icon
Gotchas Pros Uninstalling
JNLP Cons Summary
Applets Sandbox Books
Features Signing Learning More
Shortcuts Recovery Links

Trying out Java Web Start

If you have Java installed in your browser and the *.jnlp association set up, you can try out a simple Java Web Start application called SetClock which sets your PC (Personal Computer) time from an atomic clock on the web.

Installing A Java Web Start Program

First you must have a recent Java installed. Java Web Start is installed automatically when you install the runtime Java JRE.

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:
  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 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.
From then on updates are automatic. For the browser link to work, both the ISP (Internet Service Provider) and the browser must have JNLP (Java Network Launching Protocol) MIME types configured properly and the browser must associate JNLP files with Java Web Start.

Opera and Java Web Start

To run Java Web Start with the Opera browser, you need to set up an association between MIME (Multipurpose Internet Mail Extensions) type application/x-java-jnlp-file, file extension *.jnlp and application C:\Program Files\java\jre1.8.0_131\ \bin\javaws.exe. You do this by clicking Tools ⇒ Preferences ⇒ advanced ⇒ downloads ⇒ deselect hide files opened by Opera ⇒ New.

What Is a Java Web Start Application?

Java web start applications don’t require a browser to run, though they can be triggered from a browser. They don’t require an Internet connection to run, though normally would require one to download. Unlike Applets, all application jars are cached on the client and are never automatically discarded. They are a quite different sort of animal from Applets and are more closely allied to applications. Since they are only downloaded once, they can be just as large as any other Java application, e.g. running from a few K to 25 megabytes. I think of them as a Java application plus a simple installer and automatic update applier. The entire installation is controlled by a short XML (extensible Markup Language) text file with the extension *.jnlp.

Some of the terms for Java web Start applications are:




It is also possible to distribute your Applets with JWS. Then they run without a browser. You need to add an <applet-desc section to your JNLP file.
  <param name="milkshake" value="strawberry" />
  <param name="fruit" value="peach" />
The Applet runs in an AppletViewer that ignores showDocument.


For people who have dial-up Internet connections, JWS is clever. If there is a dial-up connection in progress, it checks for updates and downloads them if necessary. If there is no connection, is does not dial. It simply uses the old code and checks next time when you are connected for an update.

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.


You can configure JWS in the Java Control Panel advanced how it handles shortcuts — an optional desktop icon to launch and an optional menu item to launch your JWS app. I am having trouble with this feature which used to work fine. I have not yet tracked down what the problem is. In theory, you should be able to put hints in your JNLP file as to which shortcuts you want and the user can override those hints in the Java Control Panel to either always make the shortcuts, always skip them or always ask. You hint in JNLP with code like this in the <information> section:
<!-- hints for setting up shortcuts -->
<!-- Prefer a shortcut for online operation -->
<shortcut online="true">
  <!-- create desktop shortcut -->
  <!-- create menu item for this app under the major heading Esperanto -->
  <menu submenu="Esperanto"/>
In any case, you can safety delete desktop launch icons or menu items if JWS created them inappropriately. In JDK 1.5, you can also install or uninstall shortcuts with Start ⇒ Settings ⇒ Control Panel ⇒ Java ⇒ General ⇒ Temporary Internet Files ⇒ Settings ⇒ User ⇒ Application ⇒ right click ⇒ Install Shortcuts. This feature was removed in JDK 1.6.

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  Java Web Start short cut arrow 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. 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\\P80\DMimages\RB affirm.gif.ico

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


When you debug a Java Web Start App, unless you take special measures by composing a debugging version of your JNLP file, you will be testing the version of the JNLP file last uploaded to your website, not your recently amended local copy and you will be testing the version of your jar last uploaded to your website, or even worse, an old version in the Java Web Start cache, not your recently updated local copy. It is obvious once you think about it, but it can catch you just the same. use javaws.exe -clearcache to clear the cache.

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:
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 JDK 1.8 and Windows 7 look in: C:\Users\user\AppData\LocalLow\Oracle\Java\Deployment\SystemCache\6.0\nn\ Windows 2000 hides your jar files away in a directory with an unwieldy name like: C:\Documents and Settings\user\Application Data\Oracle\Java\Deployment\javaws\cache\http\\P80\DM~roedy\DMwebstart or "C:\Documents and Settings\user\Application Data\Oracle\Java\Deployment\javaws\cache\http\\P80\". This ponderous scheme helps avoid name collisions from different websites, even if they deploy the same application. JWS renames the files; e.g. cyberview.jar becomes RMcyberview.jar to make them harder to find. It also creates the camouflaging RCCyberview.jar for the corresponding certificate and RTCyberview.jar for some history of your use of the jar. If your Java Web Start application creates any files without taking measures to place them, they will go into a random directory, whatever happened to be the current directory at the time the program was launched.

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.


The Java Web Start java.util.prefs.Preferences on Windows uses the registry to store persistent configuration information for your applications. Check the registry My Computer/HKEY_CURRENT_USER/Software/JavaSoft/Prefs for the entries.

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 use JavaScript to detect whether a browser has been configured to understand the JNLP mime type, which is the usual barrier to running JWS applications. Here is the JavaScript code you need to generate the above display:

You can test your Java Web Start installation with some of

What’s Right With Java Web Start

What’s Wrong With Java Web Start


Unsigned JWS apps work in a restricted environment similar to the unsigned Applet sandbox. Unsigned JWS apps may print with the user’s permission. Web Start uses the same jar-signing mechanism that Applets use. Java Web Start provides a secure API that enables an application to import and export files from the local disk under the user’s control, much the way they can choose and save files in HTML (Hypertext Markup Language). Unlike an unsigned Applet, an unsigned JWS app can read and write its own files without user permission. There is still no way for even a signed JWS app to find some persistent disk space in an easy way. You ween do write an install class that to ask the user for the name of some directory to use.

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


You normally bundle your Java Web Start application up into signed jars, just as you would a signed Applet.
You must sign all the jars and sign them all with the same certificate.
In theory you can write unsigned Java Web Start apps, but there are so many restrictions on them, in practice you probably never will. For example, you can’t examine any user properties. See the limitations of the sandbox above.
You sign java web start jar apps with same code signing certificate and use the same tool jarsigner.exe. You usually build you apps and create the jars with ant, just as you would any Applet or application.

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:

Conveniently, Java only asks the user to OK the master certificate.

Recovering From Java Web Start Failures

Distributing Java Web Start Apps on CD (Compact Disc)

I have figured out a kludge to distribute Java Web Start Applications on CD. I use it in The Replicator. The main problem is the codebase parameter in the JNLP file must be absolute and match its actual location. In other words, if the CD is in drive R: then the codebase in the JNLP file must be file://localhost/R:/. If it is drive W: then the JNLP file must contain a codebase parameter file://localhost/W:/. My solution was to automatically generate 26 variants on the JNLP file and put them all on the CD. The user could then wake up Java Web Start and feed it the appropriate URL matching their CD ROM (Read Only Memory) drive letter.

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 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
to allow you to override the codebase on the command line. This is not user friendly for manually typing. No technopeasant has a hope in hell of typing that correctly.

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.


You can protect a JNLP file from public access by putting the link and jnlp file in a password-protected directory. If you can’t get a browser to access it, you can access it directly from Java Web Start by keying in an url that embeds the userid and password like this where roedy is your userid and sesame is your password.

Applets vs JWS vs Applications

How do you decide whether to use an Applet or a Java Web Start Application or an app installed with a conventional installer such as InstallAnywhere.
Applets vs JWS vs Applications
Feature Applets JWS Applications
Requires browser to run?
Must wait for download every time?
How To Install Just view a page containing the Applet. Just click a button on a page to install the JWS application. Download and run an install package.
Digitally Signed Yes, to do anything interesting. However, simple Applets can be unsigned. usually
Client Prerequisites Requires Java JRE installed on machine and in browser. Requires Java JRE installed on machine. Requires application/x-java-jnlp-file MIME type association to javaws.exe set up in browser. Requires *.jnlp association to javaws.exe The installer can automatically install a JRE for you. The install does not require a functioning JRE on the client to get started.
Server Prerequisites just a vanilla HTTP server to serve web pages and jar files. So no special server side code is needed. requires *.jnlp files be served with application/x-java-jnlp-file MIME type. Ideally you also install the JNLP protocol to serve jar changes more efficiently, though it is not necessary. just a vanilla HTTP server to serve web pages and exe files. So no special server side code is needed.
Ease of Writing Must be designed as an Applet from the start. You can turn any ordinary application into a JWS one by adding *.jnlp file and perhaps an installer class. Requires an install script for the installer and an expensive install bundler.
User Comfort
Fear Factor
below average. Ironically, MS propaganda has users fearing Applets far more than JavaScript when, in actuality, Java is hundreds of times safer. poor This is how the user normally installs programs. The user can’t tell the install apart from another other install written in C/ C++.
File Placement Difficult to find a spot to save your data. Requires signed Applets. You must ask the user then use the Preferences api or the server to persist that choice. JWS automatically allocates you storage, but gives it an ugly meaningless directory name. You can ask the user where to put files as part of your application installer and use the Preferences api to persist it. You could get at the user.dir property to assign space. User decides directory name as part of the installs, based on a default. The installer leaves notes where to find things for the application.
Start Up Time Applets load in their entirely every time over the web. There is some caching. JWS only downloads your app when it has changed. However, it dithers quite along time deciding if it really reads to download it. Especially if you use native compilation, the start up is quick, however, there is no guarantee you are using the latest version.
Speed of Execution Your Applet must share RAM (Random Access Memory) with a fat RAM-hogging browser. JWS always works with java.exe Hotspot. With a standalone app, you have the option of AOT (Ahead Of Time) compilation for extra speed.
Native Code Using signed Applets is extremely difficult with JNI native code because of the difficulty of getting the DLL s installed suitably on the path. JWS automatically handles placing JNI DLLs (Dynamic Link Libraries) on the path and selecting the version, e.g. Mac or PC suitable for the current platform. You need to use a third-party installer such as InstallAnywhere to arrange for the right version of the DLL s to installed and the path modified to point to them.

Java Web Start Icon

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.


There are several ways to uninstall a Java Web Start App. If one method fails, try another. I have found Java Web Start not very bright about uninstalling apps installed by earlier versions of Java Web Start. This suggests it cautious people might delete Java Web Start apps prior to installing a new JRE/JDK and recreating the shortcuts.

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.


I like Java Web Start for the following reasons: The key benefit of Applets is simplicity for the user. The key benefit for Java Web Start is automatic update without having to download the entire program every time. The key benefit of an application installer is you don’t need a working JRE to start.
Java Web Start is quite fragile. Apps mysteriously stop working without clues to the cause. Oracle does not take upward compatibility of Java Web Start very seriously. It is thus not suitable for crucial apps. The other problem is debuggers don’t handle Java Web Start. You must strip out all JNLP stuff out of them for debugging.


book cover recommend book⇒Java Deployment with JNLP and Web Startto book home
by Mauro Marinilli 978-0-672-32182-5 paperback
publisher Sams
published 2001-09-29
470 pages.
Australian flag abe books anz abe Canadian flag
German flag abe Canadian flag
German flag Chapters Indigo Canadian flag
Spanish flag Chapters Indigo eBooks Canadian flag
Spanish flag abe American flag
French flag abe American flag
French flag Barnes & Noble American flag
Italian flag abe Nook at Barnes & Noble American flag
Italian flag Kobo American flag
India flag Google play American flag
UK flag abe O’Reilly Safari American flag
UK flag Powells American flag
UN flag 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.





Older Material

This page is posted
on the web at:

Optional Replicator mirror
on local hard disk J:

Canadian Mind Products
Please the feedback from other visitors, or your own feedback about the site.
Contact Roedy. Please feel free to link to this page without explicit permission.

Your face IP:[]
You are visitor number