• Oracle Technology Network
• Software Downloads
• Documentation

Search

Q: Why should I encourage people to use the Java Platform?

A: The Java Platform is richer than its predecessors in functionality, performance, and security options. As a developer, you want the users of your software to have the most feature-complete Java platform possible so that the full range of APIs and libraries are available for your applications. If your customers are using the Java Platform, you can write more powerful, robust, and full-featured applications and applets. And with the Java Platform the performance of your code will be better too.

By using the latest Java Plug-in with APPLET tag support, you can help to ensure that clients running your applets will have the latest Java Platform.

Q: Can I continue to use OBJECT tags to call my applets?

A: Yes. Even though the Java Plug-in has been enhanced to support APPLET tags, it is fully backward compatible with existing web pages that use OBJECT tags to launch applets.

Q: Are there compatibility issues with using the Java Platform?

A: In the large majority of cases, there are no compatibility issues to be concerned about when moving from JDK 1.1 to the Java Platform. The documentation for a given Java Platform release describes all known incompatibilities, most of which are in the category of "corner cases." For example, known compatibility issues in version 1.4 of the Java Platform are described at http://java.sun.com/j2se/1.4/compatibility.html.

Some old class files generated by early bytecode compilers do not strictly conform to the proper class-file format, and the Java Runtime Environment may not load such classes.

In addition to compatibility issues between different releases of the Java platform, there is the question of incompatibilities between Sun's Java runtime environment and other Java runtime environments; e.g., the one included with some Internet Explorer browsers. Sun has made a great effort to minimize such incompatibilities. Among the steps that Sun as taken in this JRE/Java Plug-in are the following:

• The classloader sharing policy in Java Plug-in has been changed to minimize incompatible behavior in applets that depend explicitly on the classloader sharing policy of the Microsoft VM.
• The image and sound resource lookup sequence in Java Plug-in has been changed to give resources specified with the HTML archive paramater priority over those on the codebase URL. This change was made to minimize incompatible behavior for applets that rely explicitly on the resource lookup sequence employed by the Microsoft VM.
• The implementation of AppletgetParameter() has been modified to strip off leading and trailing whitespace from parameters before they are returned to the applet. This is the behavior of the Microsoft VM in some Internet Explorer browsers, and this change was made to eliminate possible incompatibile behavior in applets that rely explicitly on that behavior.

Q: What security model does Java Plug-in use?

A: JRE/Java Plug-in is a product in the Java Platform family, and it uses the new Java Platform's security model. This security model is more flexible and configurable than the security model used by JDK 1.1. For more information, see the Java Platform's security documentation at http://java.sun.com/j2se/1.4/docs/guide/security/index.html.

Note that applets that rely explicitly on proprietary technology in the security model of the Microsoft VM may not work with Java Plug-in.

Q: My applet fails with a ClassFormatError. What's wrong?

A: This problem may be caused by bytecode generated by old compilers. Such bytecode may not conform to the virtual machine specification, which is more strictly enforced by recent releases of the JRE.

Q: Why doesn't Java Plug-in load my applet's cab file?

A: The Java Plug-in supports applet packaging in .jar files. It does not support the Microsoft proprietary .cab file format. Therefore any applets packaged in Microsoft's .cab file format will not load in JRE/Java Plug-in.

Q: Will my Authenticode-signed applet work with Sun's JRE/Java Plug-in?

A: No. The Sun JRE/Java Plug-in does not support Microsoft proprietary technology such as Authenicode signing and .cab file formats. Signed applets that rely on Microsoft's Authenticode technology will not load in JRE/Java Plug-in.

Q: My applet uses J/Direct, AFC, and WFC, etc. Will it work in Sun's JRE/Java Plug-in?

A: No. Libraries for these and other proprietary Microsoft technologies are not included with JRE/Java Plug-in. Applets that rely on these Microsoft proprietary technologies will not work properly when run on JRE/Java Plug-in.

Q: Why does my applet throw a NullPointerException from the AWT Dispatch Event thread?

A: The events that occur during applet startup and shutdown may differ between the Microsoft and Sun implementation of the Java platform. For example, the logic in an applet may rely on the applet being visible when Applet.start()/Applet.stop() is called. That condition may be true when the applet is run on Microsoft's implementation but may not be true on Sun's impelementation.

Applets that rely on specific events that occur during startup and shutdown on Microsoft's implementation of the Java platform may not work properly with JRE/Java Plug-in. The most common symptom of this type of problem is a NullPointerException from the AWT Dispatch Event thread.

Q: Why does my applet throw a ClassCastException from the AWT Dispatch Event thread?

A: The number of containers between the applet and the encompassing frame are different in the Microsoft and Sun implementations. Therefore, an applet that relies on the frame being at some particular level of containment in the Microsoft VM, without navigating the entire AWT hierarchical component tree, is likely to fail when run on Sun's JRE/Java Plug-in. The most common symptom of this problem is a ClassCastException from the AWT Dispatch Event thread.

Q: Does Java Plug-in support Java-JavaScript communication?

A: Yes, Java Plug-in supports basic, bidirectional Java-JavaScript communication. The following, however, is a known incompatibility.

In the Microsoft implementation, applet methods and properties exposed in JavaScript are exactly the same as the methods and fields in the applet object. In Java Plug-in, an applet's methods and properties are exposed in JavaScript through JavaBeans^TM introspection, which treats the applet's fields in a different manner than the Microsoft VM. Therefore, JavaScript accessing fields in an applet object may not work the same when run on JRE/Java Plug-in.