Java Web Start Core Java

  • Java Web Start is a technology for delivering applications over the Internet. Java Web
    Start applications have the following characteristics:
  • They are typically delivered through a browser. Once a Java Web Start application has been downloaded, it can be started without using a browser.
  • They do not live inside a browser window. The application is displayed in its own frame, outside the browser.
  • They do not use the Java implementation of the browser. The browser simply launches an external application whenever it loads a Java Web Start application descriptor. That is the same mechanism that is used to launch other helper applications such as Adobe Acrobat or RealAudio.
  • Digitally signed applications can be given arbitrary access rights on the local machine. Unsigned applications run in a “sandbox,” which prohibits potentially dangerous operations.

To prepare an application for delivery by Java Web Start, you package it in one or more JAR files. Then you prepare a descriptor file in Java Network Launch Protocol (JNLP) format. Place these files on a web server.

You also need to ensure that your web server reports a MIME type of application /x -javajnlp - file for files with extension .jnlp. (Browsers use the MIME type to determine whichhelper application to launch.) Consult your web server documentation for details.

TIP: To experiment with Java Web Start, install Tomcat from tomcat. Tomcat is a container for servlets and JSP pages, but it also serves web pages. It is preconfigured to serve the correct MIME type for JNLP files.

Let’s try out Java Web Start to deliver the calculator application. Follow these steps:

  1. Compile
  2. Prepare a manifest file Calculator.mfwith the line
    Main-Class: Calculator
  3. Produce a JAR file with the command
    jar cvfm Calculator.jar *.class
  4. Prepare the launch file Calculator.jnlpwith the following contents:
  5. (Note that the version number must be 1.5.0, not 5.0. As of Java SE 6, you can use java instead of j2se for the tag name.) The launch file format is fairly self -explanatory.

  6. If you use Tomcat, make a directory tomcat/webapps/calculator, where tomcat is the base directory of your Tomcat installation. Make a subdirectory tomcat/webapps/calculator/WEB-INF, and place the following minimal web.xml file inside the WEB-INF subdirectory:
  7. Place the JAR file and the launch file on your web server so that the URL matches the codebase entry in the JNLP file. If you use Tomcat, put them into the tomcat/webapps/calculator directory.
  8. Make sure that your browser has been configured for Java Web Start, by checking that the application /x -java -jnlp -file MIME type is associated with the javawsapplication. If you installed the JDK, the configuration should be automatic.
  9. Start Tomcat.
  10. Point your browser to the JNLP file. For example, if you use Tomcat, go to
  11. You should see the launch window for Java Web Start.
  12. Launching Java Web Start

    Launching Java Web Start

  13. Soon afterward, the calculator should come up, with a border marking it as a Java application.
  14. The calculator delivered by Java Web Start

    The calculator delivered by Java Web Start

  15. When you access the JNLP file again, the application is retrieved from the cache.
    You can review the cache content by using the Java Plug-in control panel. As of Java SE 5.0, that control panel is used both for applets and Java Web Start applications. In Windows, look for the Java Plug-in control inside the Windows control panel. Under Linux, run jdk/jre/bin/ControlPanel.

The application cache

The application cache

TIP: If you don’t want to run a web server while you are testing your JNLP configuration, you can temporarily override the codebase URL in the launch file by running javaws -codebase.

For example, in UNIX, you can simply issue this command from the directory containing the JNLP file:

  javaws -codebase  file://`pwd` WebStartCalculator.jnlp

Of course, you don’t want to tell your users to launch the cache viewer whenever they want to run your application again. You can have the installer offer to install desktop and menu shortcuts. Add these lines to the JNLP file:

When the user first downloads the application, a “desktop integration warning” is displayed .

The desktop integration warning

The desktop integration warning

You should also supply an icon for the menu shortcut and the launch screen. Sun recommends that you supply a 32 × 32 and a 64 × 64 icon. Place the icon files on the web server, together with the JNLP and JAR files. Add these lines to the information section of the JNLP file:

Note that these icons are not related to the application icon. If you want the application to have an icon, you need to add a separate icon image into the JAR file and call the set -Icon Image method on the frame class.

The Sandbox

Whenever code is loaded from a remote site and then executed locally, security becomes vital. Clicking a single link can launch a Java Web Start application. Visiting a web page automatically starts all applets on the page. If clicking a link or visiting a web page could install arbitrary code on the user’s computer, criminals would have an easy time stealing confidential information, accessing financial data, or taking over users’ machines to send spam.

To ensure that the Java technology cannot be used for nefarious purposes, Java has anelaborate security model that we discuss in detail in Volume II. A security managerchecks access to all system resources. By default, it only allows those operations that are harmless. To allow additional operations, the code must be digitally signed and the user must approve the signing certificate.

What can remote code do on all platforms? It is always ok to show images and play sounds, get keystrokes and mouse clicks from the user, and send user input back to the host from which the code was loaded. That is enough functionality to show facts and figures or to get user input for placing an order. The restricted execution environment is often called the “sandbox.” Code that plays in the sandbox cannot alter the user’s system or spy on it.

In particular, programs in the sandbox have the following restrictions:

  • They can never run any local executable program.
  • They cannot read from or write to the local computer’s file system.

They cannot find out any information about the local computer, except for the Java version used and a few harmless operating system details. In particular, code in the sandbox cannot find out the user’s name, e-mail address, and so on.

  • Remotely loaded programs cannot communicate with any host other than the server from which they were downloaded; that server is called the originating host. This rule is often called “remote code can only phone home.” The rule protects users from code that might try to spy on intranet resources. (As of Java SE 6, a Java Web Start application can make other network connections, but the program user must consent.)
  • All pop-up windows carry a warning message.This message is a security feature to ensure that users do not mistake the window for a local application. The fear is that an unsuspecting user could visit a web page, be tricked into running remote code, and then type in a password or credit card number, which can be sent back to the web server. In early versions of the JDK, that message was very ominous: “Untrusted Java Applet Window”. Every successive version watered down the warning a bit—“Unauthenticated Java Applet Window”, then “Warning: JavaApplet Window”. Now it is simply “Java Applet Window” or “Java Application Window”.

Signed Code

The sandbox restrictions are too restrictive for many situations. For example, on a corporate intranet, you can certainly imagine a Web Start application or applet wanting to access local files. It is possible to control in great detail which rights to grant a particular application. Of course, an application can simply request to have all permissions of a desktop application, and quite a few Java Web Start applications do just that. This is accomplished by adding the following tags to the JNLP file:

To run outside the sandbox, the JAR files of a Java Web Start application must be digitally signed. A signed JAR file carries with it a certificate that indicates the identity of thesigner. Cryptographic techniques ensure that such a certificate cannot be forged, andthat any effort to tamper with the signed file will be detected.

For example, suppose you receive an application that is produced and digitally signed by yWorks GmbH, using a certificate issued by Thawte. When you receive the application, you will be assured of the following:

  1. The code is exactly as it was when it was signed it; no third party has tampered with it.
  2. The signature really is from yWorks.
  3. The certificate really was issued by Thawte.(Java Web Start knows how to check certificates from Thawte and a few other vendors.)

A secure certificate

A secure certificate

Unfortunately, that’s all you know. You do not know that the code is inherently safe. In fact, if you click on the “More Information” link, you are told that the application will run without the security restrictions normally provided by Java. Should you install and run the application? That really depends on your trust in yWorks GmbH.

Getting a certificate from one of the supported vendors costs hundreds of dollars per year. Many developers simply generate their own and use them for code signing. Of course, Java Web Start has no way of checking the accuracy of these certificates. When you receive such an application, then you know:

  1. The code is exactly as it was when it was signed; no other party has tampered with it.
  2. Someone has signed the code, but Java Web Start cannot verify who it was.

This is quite worthless; anyone could have tampered with the code and then signed it, claiming to be the author. Nevertheless, Java Web Start will be perfectly happy to present the certificate for your approval. It is theoretically possible to verify the certificate through another way, but few users have the technical savvy to do that.

An insecure certificate

An insecure certificate

Of course, many people download and run applications from the Internet every day. If you find that your users trust your application and your web infrastructure, go ahead and use a self -signed certificate. If not, give your users the benefit of safety and stay within the sandbox. With the JNLP API (which we discuss in the next section), you can still allow your program to selectively access resources, subject to user approval.


The JNLP API allows unsigned applications to run in the sandbox and at the same time access local resources in a secure way. For example, there are services to load and save files. The application can’t look at the file system and it can’t specify file names. Instead, a file dialog is popped up, and the program user selects the file. Before the file dialog is popped up, the program user is alerted and must agree to proceed.

A Java Web Start security advisory

A Java Web Start security advisory

Furthermore, the API doesn’t actually give the program access to a File object. In particular,the application has no way of finding out the file location. Thus, programmers are given the tools to implement “file open” and “file save” actions, but as much system information as possible is hidden from untrusted applications.

The API provides the following services:

  • Loading and saving files
  • Accessing the clipboard
  • Printing
  • Downloading a file
  • Displaying a document in the default browser
  • Storing and retrieving persistent configuration information
  • Ensuring that only a single instance of an application executes To access a service, you use the ServiceManager, like this:

File Save Service service = (File Save Service) Service Manager. lookup ("javax .jnlp .File Save Service");

This call throws an Unavailable Service Exception if the service is not available.

NOTE: You must include the file javaws.jar in the class path if you want to compile programs that use the JNLP API. That file is included in the jre/lib subdirectory of the JDK. We now discuss the most useful JNLP services. To save a file, you provide suggestionsfor the initial path name and file extensions for the file dialog, the data to be saved, anda suggested file name. For example:

The data must be delivered in an InputStream. That can be somewhat tricky to arrange.

The program in Listing below uses the following strategy:

  1. It creates a ByteArrayOutputStreamto hold the bytes to be saved.
  2. It creates a PrintStreamthat sends its data to the ByteArrayOutputStream.
  3. It prints the information to be saved to the PrintStream.
  4. It creates a ByteArrayInputStreamto read the saved bytes.
  5. It passes that stream to the saveFileDialogmethod.

You will learn more about streams later. For now, you can just gloss over the details in the sample program.

To read data from a file, you use the FileOpenServiceinstead. Its open File Dialog receives suggestions for the initial path name and file extensions for the file dialog and returns a File Content sobject. You can then call the get Input Streamand get Output Stream methods to read and write the file data. If the user didn’t choose a file, then the openFileDialogmethod returns null.

Note that your application does not know the name or location of the file. Conversely, if you want to open a specific file, you use the ExtendedService:

The user of your program must agree to the file access.

File access warning

File access warning

To display a document on the default browser, use the BasicServiceinterface. Note that some systems may not have a default browser.

A rudimentary Persistenc eService lets an application store small amounts of configuration information and retrieve it when the application runs again. The mechanism is similar to HTTP cookies. The persistent store uses URLs as keys. The URLs don’t have to point to a real web resource. The service simply uses them as a convenient hierarchical naming scheme. For any given URL key, an application can store arbitrary binary data.

So that applications are isolated from each other, a particular application can only use URL keys that start with its codebase (as specified in the JNLP file). An application can call the getCodeBasemethod of the BasicServiceto find its codebase. You create a new key with the create method of the Persistence Service.

To access the information associated with a particular key, call the get method. That method returns a FileContentsobject through which you can read and write the key data. For example:

Unfortunately, there is no convenient way to find out whether a key already exists or whether you need to create it. You can hope that the key exists and call get. If the callthrows a FileNotFoundException, then you need to create the key.

NOTE: Starting with Java SE 5.0, both Java Web Start applications and applets can print, using the normal printing API. A security dialog pops up, asking the user for permission to access the printer.

This calculator has a virtual paper tape that keeps track of all calculations. You can save and load the calculation history. To demonstrate the persistent store, the application lets you set the frame title. If you run the application again, it retrieves your title choice from the persistent store.

The WebStartCalculator application

The WebStartCalculator application

javax.jnlp.ServiceManager isting

  • static String[] getServiceNames()
    returns the names of all available services.
  • static Object lookup(String name)
    returns a service with a given name.


  • URL getCodeBase()
    returns the codebase of this application.
  • booleanisWebBrowserSupported()
    returns true if the Web Start environment can launch a web browser.
  • booleanshowDocument(URL url)
    attempts to show the given URL in a browser. Returns true if the request succeeded.


  • InputStreamgetInputStream()
    returns an input stream to read the contents of the file.
  • OutputStreamgetOutputStream(boolean overwrite)
    returns an output stream to write to the file. If overwrite is true, then the existing contents of the file are overwritten.
  • String getName()
    returns the file name (but not the full directory path).
  • booleancanRead()
  • booleancanWrite()
    returns true if the underlying file is readable or writable.


  • FileContentsopenFileDialog(String pathHint, String[] extensions)
  • FileContents[] openMultiFileDialog(String pathHint, String[] extensions)
    displays a user warning and a file chooser. Returns content descriptors of the file or files that the user selected, or null if the user didn’t choose a file.


  • FileContentssaveFileDialog(String pathHint, String[] extensions, InputStream data,
    String nameHint)
  • FileContentssaveAsFileDialog(String pathHint, String[] extensions, FileContents data)
    displays a user warning and a file chooser. Writes the data and returns content descriptors of the file or files that the user selected, or null if the user didn’t choose a file.


  • long create(URL key, long maxsize)
    creates a persistent store entry for the given key. Returns the maximum size granted by the persistent store.
  • void delete(URL key)
    deletes the entry for the given key.
  • String[] getNames(URL url)
    returns the relative key names of all keys that start with the given URL.
  • FileContents get(URL key)
    gets a content descriptor through which you can modify the data associated with the given key. If no entry exists for the key, a FileNotFoundExceptionis thrown.

All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd Protection Status

Core Java Topics