Appendix 4: Microsoft VM and Java 2 Applet Compatibility Issues

This appendix documents the known applet compatibility issues between the Microsoft VM (Virtual Machine) and Sun's Java 2 VM.

ClassFormatError

This problem is caused by bytecode generated from old JDK 1.0.2 or 1.1 compilers, which generate bytecode that does not conform to the Java VM Specification. Since the verifiers in recent J2SE releases are much stricter about bad class format, ClassFormatError is thrown by the VM when these bad class files are loaded.

To allow some applets with bad class file format to run in Java 2, a bytecode transformer is put into the Java Plug-in to transform some of the bad class files to good ones. Currently only bad class files with the following ClassFormatError may be transformed:

Unfortunately, the following ClassFormatError is not fixable by the bytecode transformer, so any class file that has any of these known problems will not run under Java 2:

Security exception with sun.audio

The sun.audio package was accessible by applets in JDK 1.1. However, the applet sandbox was closed up in Java 2, so that applets that try to access any class libraries in the sun.audio package will result in a SecurityException. 

To provide maximum applet compatibility, the applet sandbox in Java Plug-in has been opened up to allow applets to access the sun.audio package again.

Unable to find resources from AppletContext.getAudioClip() and AppletContext.getImage()

The resource-lookup sequence in AppletContext.getImage() and AppletContext.getAudioClip() is different in the Microsoft and Sun implementations. 

In the Microsoft VM, resources are looked up in the following sequence:

  1. Archives specified through HTML archive or cabbase parameters
  2. codebase URL

In Sun's implementation, resources are looked up according to codebase URL.

As a result, some applets that rely on the resources-lookup sequence in the Microsoft VM may not load resources properly in Java 2. 

To provide maximum applet compatibility, the resources-lookup sequence in Java Plug-in has been changed to the following:

  1. Archives specified through HTML archive parameters
  2. codebase URL

ClassLoader sharing policy

ClassLoader sharing policy is different in the Microsoft and Sun implementations. 

In the Microsoft VM, the ClassLoader object is shared between applets if and only if all of the following are true:

In Sun's implementation, a ClassLoader object is shared between applets if and only if:

Some applets relying on the ClassLoader sharing policy in the Microsoft VM may not run properly in Java 2 because of potential class definition conflicts. 

To provide maximum applet compatibility, the ClassLoader sharing policy in Java Plug-in has been changed to the following requirements:

Security model—Java 2 Versus Microsoft

Java 2 has a new security model providing much more capability and flexibility than JDK 1.1 provides. The Microsoft VM security model is based on JDK 1.1 and its own propriety technologies. 

This issue is not fixable, so applets that rely on the Microsoft's security model will not run properly in Java 2.

Applet packaging

Applet packaging in Java 2 and JDK 1.1 is through the .jar file. However, Microsoft's VM supports applet packaging through .jar file and its own propriety .cab (cabinet) file. 

This issue is not fixable, so applets packaged in Microsoft's .cab file format will not load in Java 2.

Java language specification strictness (null versus zero-length String)

In JDK 1.1, the Java language specification was loose in dealing with null and zero-length strings in the class libraries. Some APIs may treat null as a zero-length String, while some other APIs may treat null as it is. In Java 2, the Java language specification has been tightened up to specify what the exact behavior should be. 

This issue is not fixable, so applets that rely on the APIs to treat null as a zero-length String may result in an exception in Java 2.

Applet signing—RSA versus Authenticode

In Java 2, applet signing is supported through RSA and the .jar file, while Microsoft supports applet signing through its own proprietary Authenticode and .cab technologies.

This issue is not fixable, so signed applets that rely on Microsoft's Authenticode and .cab technologies may not load properly in Java 2.

Implementation changes in AWT class libraries

In JDK 1.1, AWT class libraries were used by developers as thread-safe libraries; i.e., applets may perform lots of actions through the AWT in multiple threads and assume the class libraries will take care of synchronization issues. In Java 2, the AWT class libraries implementation has been changed to guarantee thread safety only when it is called by the AWT event-dispatch thread. 

This issue is not fixable, so applets in Java 2 that make calls to AWT class libraries without awareness of the thread-safety issue may result in deadlock or race conditions.

Java/JavaScript communication

In the Microsoft implementation, applet methods and properties exposed in JavaScript in an HTML page are exactly the same as the methods/fields of the applet object. In Java Plug-in, applet methods and properties exposed in JavaScript in HTML are obtained via JavaBeans Introspection, which analyzes methods and properties through naming convention in the applet object. The side effect is that applet fields are treated differently.

This problem will be fixed in future release of Java Plug-in. In the meantime, JavaScript accessing fields in the applet object may not work properly in Java 2.   

Microsoft proprietary Java class libraries

Microsoft has provided lots of proprietary class libraries in its VM implementation, including J/Direct, AFC, WFC, etc.

This issue is not fixable, so applets that rely on any of the Microsoft proprietary Java class libraries will not work properly in Java 2.

Whitespace characters in string returned from Applet.getParameter()

In the Microsoft implementation, whitespace characters are stripped off before the string is returned to the applets in Applet.getParameter(). However, the Sun implementation returns the string as it is specified in the HTML parameters. As a result, some JDK 1.1 applets refuse to run in Java 2 because the applet's logic doesn't take the whitespace into account.

To provide maximum applet compatibility, the implementation of Applet.getParameter() in Java Plug-in has been changed to strip off whitespace characters in the return value.

Design changes in java.util.Hashtable.hashCode()    

In JDK 1.1, Hashtable.hashCode() was implemented based on object identity, so that each Hashtable object returns its unique value when hashCode() is called. In Java 2, implementation of Hashtable.hashCode() was changed to be value-based as part of the Java Collection Framework. Hashtable object returns its hashcode value based on the objects it contains.  

This change breaks some JDK 1.1 applets if they add Hashtable object into itself, as this breaks the fundamental design of the Collection Framework and causes a StackOverflowError. It breaks the logic in the code of some applets that rely on Hashtable.hashCode() to return a constant value from the same Hashtable object.

To provide maximum applet compatibility, the implementation of Hashtable.hashCode() is changed to check for this special case and avoid stack overflow.

Accessing frame from applet

To track mouse events or for other reasons, an applet may sometimes try to access to its frame. In the Microsoft and Sun implementations, the number of containers between the frame and the applet is different.

An applets that relies on the location of its frame being at a particular level of containment in the Microsoft VM (without navigating the entire AWT hierarchical component tree) is likely to fail in Java 2. The most common symptom is ClassCastException from the AWT Dispatch Event Thread.

This issue is not fixable; thus an applets affected by this issue may not run properly in Java 2.

MAYSCRIPT

In Netscape Navigator and Java Plug-in, an applet accessing JavaScript is required to specify the MAYSCRIPT parameter in the applet tag. However, the Microsoft implementation doesn't honor this parameter and allows applets to access JavaScript under all conditions. Since most Internet applets target the Microsoft VM, MAYSCRIPT is not specified in these applets.

To provide maximum applet compatibility, the MAYSCRIPT check has been removed from Java Plug-in.

HTTP User-Agent

In the Microsoft and Sun implementations, different HTTP User-Agent strings are passed to the server when an HTTP connection is requested. Since most web sites target the Microsoft VM instead of Sun's, these web sites do not recognize Sun's HTTP User-Agent, and this may result in failure.

As a result, HTTP User-Agent used in Java Plug-in has been changed to be similar to the one in the browser; thus most web servers will recognize requests made from applets running in Java Plug-in.

Events during applet startup and shutdown

In the Microsoft and Sun implementations, the events occurring during applet startup and shutdown may not be exactly the same. For example, the logic in the applet may rely on the applet being visible when Applet.start()/Applet.stop() is called, which may be true in Microsoft's implementation but not in Sun's.

Applets that rely on specific events during applet startup or shutdown in Microsoft's VM may not function properly in Java 2. The most common symptom is NullPointerException from the AWT Dispatch Event Thread.

This issue is not fixable.

Java class libraries compatibility 

There are lots of changes in the Java class libraries in Java 2. Some APIs are clarified, some are depreciated, and some other have been altered in implementation. These following have caused some of the applets run in Microsoft's VM to fail in Java 2:

java.awt.Graphics.drawString()

drawString() treats null as an empty string in the Microsoft VM. In Java 2, drawString() treats null as it is and throws NullPointerException.

java.awt.Graphics.drawImage()

drawImage() ignores null image in the Microsoft VM. In Java 2, drawImage() treats null as it is and throws NullPointerException.

java.awt.Color constructors

In the Microsoft VM, passing over-bound/under-bound values in the Color constructor will cause the VM to print out a warning message in the console, but the values will be reset to max/min automatically. In Java 2, Color constructor checks for illegal values and throws IllegalArgumentException.

Thread.stop(), Thread.suspend(), Thread.resume()

In the Microsoft VM, stopping, suspending, or resuming a dead thread will cause the call to be ignored. In Java 2, calling these methods on a dead thread will result in AccessControlException.

All of these issues are fixable but have not yet been fixed. At this time, applets affected by these issues will result in exceptions and may not run properly in Java 2.