Client-side deployment with applets and JNLP

— 7 minute read

In the previous posts, on socket programming and JDBC, the focus has been on programming for the server. This post will focus on client-side programming: applets and web start – with particular focus on the latter.

Java Web Start

The Java Network Launch Protocol (JNLP) specifies how to deliver a desktop application over the internet. A webpage may link to a *.jnlp file, and when you download it, the JVM is invoked and will parse the file and download or stream the Java classes of the application, and run the application as if it were on your desktop (not within the browser).

Sun has a full-blown tutorial on how to develop, deploy and run Java Web Start applications – it is a significantly trickier task to accomplish than with standard JAR file distributions; and rightly so, because applications deployed over networks need tighter security at several different levels.

By default, Java applications deployed or running over networks, including Java web start applications, are sandboxed by the security manager of the JVM. A sandbox may be thought of as a restricted environment. This means that the instruction set they are allowed to use is severely restricted such that only completely harmless operations are permitted. For these applications to gain more access rights on the local machine (the client machine on which it is deployed or running), the JAR files need to be digitally signed. Again, the Sun tutorial has a detailed explanation about what this involves. Some of the restrictions include:

  • Cannot I/O to local files or execute them
  • Can only phone home to the host from which it was downloaded – not to other clients or servers
  • Warning messages displayed to user

Applets

Applets are another means to run remote code on a client machine. They differ significantly from the Java Webs Start because they do not run as a desktop application, but rather via a browser plug in.

JApplet is a Swing component; however it inherits from neither JComponent nor JFrame. Instead, it inherits from Applet, which is an AWT component.

Deploying an applet on a web page

W3.org’s <object> tag definition | Sun tutorial on Applets

The Sun tutorial and the W3.org specification disagree at the time of writing – the Sun tutorial still is uses the <applet> tag, whereas the W3.org specification says that the <applet> tag has been deprecated in favour of the object tag. The <applet> still tag works on all Java enabled browsers, and it is not too much effort to switch from one to the other – the commonly used attributes are almost identical. In the examples below, the only difference is that the “code” attribute is replaced by the “classid” attribute”.

Using the applet tag:

<applet code="some.package.MyApplet"
   archive="dist/myApp.jar"
   width="400px" height="300px">
      <param name="myString1" value="myValue1" />
      <param name="myDouble2" value="2.0" />
</applet>

Using the object tag:

<object classid="some.package.MyApplet"
   archive="dist/myApp.jar"
   width="400px" height="300px">
      <param name="myString1" value="myValue1" />
      <param name="myDouble2" value="2.0" />
</object>

Java applet code

Before jumping into coding the applet, it is a good idea to think about JApplet’s inheritance hierarchy. Because it inherits from neither JComponent nor JFrame, it will be missing some API (such as setTitle(String), and setSize(int, int)), and behave differently. A word of caution also that JApplet has some interesting painting and layout quirks, thus as a rule of thumb, avoid doing any GUI design work directly inside of an applet – instead do all the GUI design work in a JPanel, and then put the JPanel inside the JApplet.
Another important distinction to make is the entry point into a standard Java application is different from the entry point into a Java applet. A standard Java application always needs (at least) one class that contains the special method with the signature:

public static void main (String[] args)

This is its entry point, and any command line arguments get passed in via the string array. However, in the applet, there is no “main” method, and certainly no array of strings for command line arguments. However, the same effect is achieved using the init() method of the applet, and the parameters passed in using the <param> tags within the <applet> or <object> tags.

public class MyApplet extends JApplet {
   private String myString1;
   private double myDouble2;
   public void init() {
      myString1 = getParameter("myString1");
      myDouble2 = Double.parseDouble(getParameter("myDouble2"));
   }
}

Once this is done, you can do anything with an applet that you can with any other java application. Note that the same security restrictions still apply to code that is deployed over a network – the applets can be sandboxed.

Applets’ external communications

Applets can communicate with other applets, the browser, and any other machine through sockets. However, if the applet is sandboxed, its socket communications will be restricted to only the host machine they originate from.
Applets communicate with other machines through sockets, in the same way that a standard Java application does. See my previous post on socket programming in java for more details.

Applets can communicate with other applets running in the same environment (which in most cases are the other applets in the same web page). They do this through the AppletContext interface. In order to do this, each applet must have a name. This is not a class name, but a unique ID for each applet within the web page. To do this, just add a “name” attribute to each of the <applet> tags or <object> tags.

       Applet receiver = getAppletContext().getApplet("myApplet2");
       if ((receiver != null) && (receiver instanceof MyApplet)) {
           ((MyApplet)receiver).sendMessage(message);
       } else {
           System.err.println("The other applet was not found");
       }

The code above shows how one applet obtains the AppletContext, and uses this to obtain a reference to another applet on the same web page, whose name attribute is “myApplet2″. If such an applet is found, it type casts it to a particular class of Applet (in this case MyApplet), so that it may invoke a method particular to his type of applet – the sendMessage(String) method, which it uses to transmit the contents of the “message” variable. Thus, intra-web page applet communication is achieved.

Applets can also communicate with the browser. This is also achieved via the AppletContext interface. Invoke the AppletContext#showDocument(URL) method to tell the browser to navigate to a new location. Invoke the AppletContext#showStatus(String) method to change the text in the status bar of the browser.

       Applet receiver = getAppletContext().getApplet("myApplet2");
       if ((receiver != null) && (receiver instanceof MyApplet)) {
       ((MyApplet)receiver).sendMessage(message);
       } else {
           System.err.println("The other applet was not found");
       }