JWS (Java Web Start) is the official spelling, though you will he half a dozen variants.
Sun’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
Sometimes called JWS (or improperly JAWS (Java Web Start).
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
- a mechanism to select the best fit JRE (Java Runtime Environment) javaw.exe.
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
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
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\jre7\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 small.
- 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)
- 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:
Things seem to have settled down, so if you are using the latest Java, you should count on the version at:
- J:\Program Files\java\jdkXXX\jre\javaws\Java Web Start
- 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\jre7\javaws\javaws.jar in the
in J:\Program Files\java\jdk1.7.0_40\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.7.0_40\sample\jnlp\servlet\jnlp.jar
or set the classpath environment variable like this:
copy J:\Program Files\java\jdk1.7.0_40\sample\jnlp\servlet\jnlp.jar
SET CLASSPATH=.;C:\;E:\;J:\Program Files\java\jdk1.7.0_40\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
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
- 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 IE 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
<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. Sun provides a reference Servlet in the download that implements
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.
I am not sure which of the above projects are client/server or both.
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:
- 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 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
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
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
<!-- 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 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
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
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\jre7
\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
Then you can right click drag ⇒ copy that desktop icon wherever you want onto
When you debug a Java Web Start App, unless you take special measures by composing a debugging version of your
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, not your
recently updated local copy. It is obvious once you think about it, but it can catch you just the same.
If you type javaws 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.
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?
Java Web Start with Java version 1.5 and Windows 2000 hides your jar files away in a directory with an unwieldy name like:
C:\Documents and Settings\Administrator\Application Data\Sun\Java\Deployment\javaws\cache\http\Dwww.songprojector.com\P80\DM~roedy\DMwebstart
or C:\Documents and Settings\Administrator\Application Data\Sun\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
In Java version 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
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
mime type, which is the usual barrier to running JWS applications.
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
- 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
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
- It needs a rigid scheme to assign hard disk space on the client’s machine that has the following
- 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.
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
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
- 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
- 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.
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 application.
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
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 JNLP
file includes an auxiliary JNLP
file (which references jars signed with a different certificate) by inserting a line like this in the
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\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 (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
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
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 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/W98 and cmd.exe for
NT/W2K/XP/W2003/Vista/W2008/W7-32/W7-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
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
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. 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 Java version 1.5 or later, Sun 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
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
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
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 online
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|
|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.|
||Yes, to do anything interesting. However, simple Applets can be
||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
||The installer can automatically install a JRE for you. The install does not require a functioning
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
||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
|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.|
|below average. Ironically, MS propaganda has users fearing Applets far more
||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
||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 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
||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 JNI
DLLs (Dynamic Link Libraries) on the path, and selecting the version, e.g. Mac or
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 ⇒ 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:
- At the command prompt type javaws -viewer The right click the app and select
- Use Ace Utilities To remove the entry in the control
- Look in C:\Users\userid\AppData\LocalLow\Sun\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.
- 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.
- 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,
detects that and downloads the new version automatically. It also updates the desktop icons to the new images
- You don’t get variable behaviour caused by bugs and obsolete software installed in various
- There is more free RAM without the browser there too.
- Java Web Start automatically checks for version compatibility.
||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,
Documentation, jardiff tool, jnlp-servlet.jar file and the jnlp.jar file.
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