Using the Conventional APPLET
Tag
This section includes the following topics:
JavaTM Plug-in now supports the HTML APPLET
tag for launching applets. Users may configure their browsers so that Sun's
JRE is the default runtime environment for handling APPLET tags.
Notes
- The use of the
APPLET tag is supported on all supported
operating systems and browser (see Supported
System Configurations) with the exception of Netscape 4.7x, which
is only supported on Solaris.
- Even though Java Plug-in now supports the APPLET tag, it
does not support applets that make use of proprietary technologies.
Examples of such technologies are:
- CAB files
- Authenticode signing
- Java Moniker
- With the conventional applet format, use of an attribute named
object
with a PARAM element will cause an exception with the Sun
VM: 'Either "code" or "object" should be specified, but not both.'.
With the Microsoft VM, no exception will be thrown. This is a compatibility
issue. To avoid the exception with the Sun VM, do not use an attribute
named object with a PARAM element in an applet.
|
This release of Java Plug-in supports the use of APPLET tags for
launching applets. However, it is also fully backward compatible with previous
Java Plug-in releases in its support of the OBJECT tag for launching
applets in Internet Explorer running on the Windows platform. As before, developers
have the option of using the HTML Converter to set up their applet web pages
to use the OBJECT tag.
For more information about using OBJECT tags to launch applets on
Java Plug-in, see Using OBJECT, EMBED and APPLET Tags
in Java Plug-in and Using the HTML Converter
to Convert Applet Tags for Java Plug-in.
In some cases, the new Java Runtime Environment associated with this Java Plug-in
release will not run class files that were generated with old compilers. The
usual symptom is a java.lang.ClassFormatError that the virtual machine
throws when it attempts to load such a class file. This failure has nothing
specifically to do with the changes in this release. Rather, old bytecode compilers
did not strictly adhere to proper class-file format in all situations when generating
class files. Recent virtual machines are implemented to be strict in enforcing
proper class file format, and this can lead to errors when they attempt to load
old, improperly formatted class files. Some typical problems in some older class
files are (this list is not exhaustive):
- There are extra bytes at the end of the class file;
- The class file contains method or field names that do not begin with a letter;
- The class attempts to access private members of another class;
- The class file has other format errors, including illegal constant pool
indices and illegal UTF-8 strings;
- Some early (third-party) bytecode obfuscators produced class files that
violated proper class-file format.
You can avoid this type of problem by recompiling your classes with the Javac
bytecode compiler from the current JDK. If you choose to use a third-party
obfuscator, be sure to use one that produces class files that respect proper
class-file format.
For additional information, see the Java
Upgrade Guide in the Java
Deployment Guide.
In addition to the support for the APPLET tag described above,
the Java Plug-in has many performance and architecture enhancements that will
make it more suitable for widespread use on consumer client machines that typically
are not as powerful as client platforms in an enterprise environment. Some of
these enhancements are summarized below.
Memory management
- Dynamic maximum heap size is scaled down from 128 MB to 96MB to avoid unnecessary
paging on the system.
- Classloader implementation has been tuned to allow memory to be reclaimed
more often by the garbage collector.
- Potential memory leak issue is addressed by using JNI/COM smart pointers
in implementation.
Performance
- Applet download time is significant reduced by relying on browser caching
when possible. No connection will be opened on the server side unless it is
absolutely necessary.
- Applet lifecycle is controlled asynchronously to allow very fast page switch.
- Sped up classloader object reclaim by removing its finalize()
method.
- HTTPS read has been made significantly faster by increasing buffer size.
- HTTPS calls are significant faster by statically linking Microsoft's Wininet
instead of dynamic function lookup every time.
- JavaScript performance is greatly enhanced by eliminating BeanInfo
lookup over the network.
- Java Console performance is enhanced by using the Console Writer thread
to avoid blocking System.out and System.err when possible.
Design
- Default JavaScript/Java interaction is changed from "not-scriptable"
to "scriptable", allowing any applets running through the APPLET
tag to be used from JavaScript without modification.
JDK 1.1 compatibility
- Java Plug-in can now access the sun.audio package.
- Some applets are compiled with compilers that don't generate proper class
file format which conforms to the class-file specification. Such appletss
may result in a ClassFormatError when Java Plug-in attempts to load
them. To help address this problem, PluginClassLoader provides a
bytecode scanner to transform bad class files to conforming on-the-fly to
allow the applets to run. Currently, only bad class files with the following
errors may be transformed
- Local variable name has bad constant pool index
- Extra bytes at the end of the class file
- Code segment has wrong length
- Illegal Field/Method name
- Illegal field/method modifiers
- Invalid start_pc/length in local var table
See also Updating Old Class Files above and Java
Upgrade Guide in the Java
Deployment Guide.