There are guidelines and specifications for what browsers must provide but implementation of these and any extensions is left to the browser manufacturer.
One difference among browsers is in their implementation of the security manager and security levels. What is allowed in one browser at “medium” security may not be allowed in the other. Adjustment of security is done on the client side, and each browser does it differently. For example, the mechanism for relaxing some security for an applet is signing. Signing an applet and getting the browser to accept that signature allows you more flexibility in your applet. The mechanism for this is built into Java with the Javakey utility. Unfortunately, browsers aren’t required to use this mechanism. In fact, some use their own proprietary mechanisms for signing which only work in their browser.
Another difference is that individual browser manufacturers make some adjustments to core Java functionality, including leaving some of it out. This can result in unexpected behavior at runtime. For example, you could have paint calls that do not happen, leaving the applet in an odd state, or even invisible. You can try to find a way to code around specific cases, but it is not always possible.
Also, there are often variations in Java support on different platforms from within the same browser. For example, a multi-threaded applet may run on one platform, but because of problems in the threading model on a different platform, threads may run sequentially on a different platform. Often, browsers are not updated across platforms at the same time, and a browser update for a less popular platform may be released later.
These differences increase the amount of time you have to spend testing and debugging in a particular browser.
W o r k i n g w i t h a p p l e t s 14-7
B r o w s e r i s s u e s
Solutions to browser issues
This section offers solutions for problems you might encounter when running your applet in a browser.
• Use the Java Plug-in
Most of the browser issues mentioned above can be solved by using the Java Plug-in, found at http://java.sun.com/products/plugin/. This plug-in provides up-to-date JDK archives, which is beneficial if your applet uses Swing (JFC).
You do have to modify your HTML files for the applet to use the plug-in. Sun provides a utility, the HTML Converter, that does the conversion quickly and easily. For more information on the HTML Converter, see http://java.sun.com/j2se/1.4/docs/guide/plugin/ developer_guide/html_converter.html.
Using the Java Plug-in is the only way to get the same JDK into the different browsers. You also typically get a JDK that is more current than the browser’s JDK. There are some extensions that browser manufacturers have added that may not work the same with the plug-in.
The first time an end-user encounters a Java Plug-in enabled page, he or she will be prompted to install the plug-in. Once the plug-in is
installed, the client machine will have an official VM from Sun and the latest JDK (including Swing) installed locally. This will only be used in “plug-in” aware pages, but it does cut down on the overhead of delivering the latest JDK technology to the browser.
Important There are several plug-in versions: JDK 1.1.x, 1.2x, 1.3x and 1.4. You must use the version that matches the JDK used by your applet. In addition, the HTML Converter version must match the plug-in version. Also note that you can have only one version of the plug-in on the client machine.
• Use the same version of the JDK supported by the browsers
You can avoid many problems by writing applets using the same JDK that the browsers support. JBuilder SE and Enterprise allow you to switch the JDK version you are using for development. Although JBuilder Personal does not support JDK switching, you can edit the current JDK. See Tools|Configure JDKs and “Editing the JDK” in the “Creating and managing projects” chapter of Building Applications with JBuilder.
A d d i t i o n a l t i p s f o r m a k i n g a p p l e t s w o r k
• Install the non-core Java classes on the clients
Each browser has a directory that Java uses for CLASSPATH-based
searches, so if you store the large archives that your applet uses locally, your client won’t have to download them. This is usually only possible in an intranet environment or in Internet situations where you have a controlled client set (such as in a subscription-based service). This does, however, make future code updates more difficult.
• Select one browser
Make your users use only one browser to minimize the need for special code and maintenance. This is usually only possible in intranet
situations controlled by IS policy. • Use Java Web Start
Java Web Start is a deployment technology from Sun Microsystems. It allows you to launch Java applets (and applications) from a link on a web page in your web browser. Java Web Start solves the JDK version mismatch problem. As long as the browser has the Java Web Start plug-in, it can automatically download the appropriate JDK to run the applet.
For more information on Web Start, see Chapter 15, “Launching your web application with Java Web Start,” and visit the Java Web Start page at http://java.sun.com/products/javawebstart/.