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.6.0_10, 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
- 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 kludge.properties 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
You can think of Java Web Start apps as ordinary apps plus five main extra
- 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)
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:
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.
- Click on a jnlp URL (Uniform Resource Locator)
href link in your browser like this, or type it in on the address line:
- To launch from the command line:
- 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
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_20\
\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:
- 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
- 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)
- Java Web Start now ignores the properties in the
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
button. There may be a way in there.
- If you make a syntax error in your
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
- 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:
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_20\
- 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\
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_20\
\javaws\javaws.jar in the
JRE and in
\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_20\
\lib\ext"or set the classpath
environment variable like this:
copy J:\Program Files\java\jdk1.8.0_20\
SET CLASSPATH=.;C:\;E:\;J:\Program Files\java\jdk1.8.0_20\
\sample\jnlp\servlet\jnlp.jarThe 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
- 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
type for *.jnlp and any of the other Java file types you
use such as *.class, *.java,
*.jar, *.jardiff and
*.ser. See MIME
- 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.
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
has caching turned off or a full cache.
Oracle’s Technote Guide on IE Bug
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
<param name="milkshake" value="strawberry" />
<param name="fruit" value="peach" />
The Applet runs in an AppletViewer that ignores
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
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.
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:
- It avoids making the user wait to do useful work. Most of the time the update
is not critical.
- It only bothers refreshing programs you actually are actively using.
- 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
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
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
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
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
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
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 -->
<!-- create desktop shortcut -->
<!-- create menu item for this app under the major heading Esperanto -->
In any case, you can safety delete desktop launch icons or menu items if
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
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_20\
\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
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
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
Where are the Files?
1.8 and Windows 7 look in:
Windows 2000 hides your jar files away in a directory with an unwieldy name like:
C:\Documents and Settings\user\Application
C:\Documents and Settings\user\Application Data\Oracle\Java\Deployment\javaws\cache\http\Dwww.mindprod.com\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
assigning them names completely unrelated to the
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
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
services to find you some uniquely (and hideously) named disk space.
Detecting Java Web Start
whether a browser has been configured to understand the JNLP
mime type, which is the usual barrier to running JWS
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
- 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
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
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
type both at the ISP
and in the client’s browser. Neither of these are under the developer’s
- 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
- The scheme must provide a place both for per-user and per-application
- A program should work on any platform without modification to deal with
finding its files.
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:
- 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
- no access to user properties.
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.
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
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
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
files can be signed with different certificates. Your master
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
- 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 Disk)
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
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
file and put them all on the CD.
The user could then wake up Java Web Start and feed it the appropriate
matching their CD
ROM (Read Only Memory)
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
file on the fly since the result has to be on the unwriteable
along with the jar.
The essential problem is you don’t know the drive letter of the
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 W98
and cmd.exe for NT W2K XP W2003 Vista W2008 W7-32 W7-64 W8-32 W8-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
files, is that it works only on Windows. Further, it presumes the association between
*.jnlp and javaws.exe is
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
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
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
For Windows an autorun.inf file should do it normal
thing to start the launch, as should the equivalent feature for any other
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
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 Disks)
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
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
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
reasons why to use Applets vs Java Web Start vs Applications
|Applets vs JWS
|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
||Download and run an install package.|
||Yes, to do anything interesting. However,
simple Applets can be unsigned.
||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.|
||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
||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
||You can turn any ordinary application into a JWS
one by adding *.jnlp file and perhaps an installer
||Requires an install script for the installer and an expensive install
hundreds of times safer.
||This is how the user normally installs programs. The user can’t tell
the install apart from another other install written in C/ C++.|
||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
||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
||JWS only downloads your app when it has changed.
However it dithers quite along time deciding if it really reads to download
||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.|
||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
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
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.
- 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 ⇒
- 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
- 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:
- At the command prompt type javaws -viewer The right
click the app and select delete.
- Use Ace Utilities To
remove the entry in the control panel.
- Look in
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.
- Delete the desktop icon and menu items with right click
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
- Clients don’t have to download the app every time, only when it
- 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.
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
stuff out of them for debugging.
Book referral for Java Deployment with JNLP and Web Start
||recommend book⇒Java Deployment with JNLP and Web Start|
|Greyed out stores probably do not have the item in stock. Try looking for it with a bookfinder.|
The Java Web Start runtime comes bundled with the JDK or JRE, includes Application
Developer’s Guide, Download Servlet Guide, JNLP.
Documentation, jardiff tool, jnlp-servlet.jar file and the jnlp.jar file.
Oracle’s Technote Guide on Java Web Start FAQ
Oracle’s Technote Guide on Java 1.7 Java Web Start
Oracle’s JWS api for javax.jnlp Java Web Start API
Oracle’s Technote Guide on JNLP Syntax
Oracle’s Technote Guide on Java Web Start Enhancements in Java 1.6
Oracle’s Technote Guide on JNLP spec 6.0.10 online