# Using the Conventional `APPLET` Tag

This section includes the following topics:

- Support for the `APPLET` Tag
- Compatibility with the `OBJECT` Tag
- Updating Old Class Files
- Other Enhancements

## Support for the `APPLET` Tag

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.

## Compatibility with the `OBJECT` Tag (Internet Explorer on Windows Platform)

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.

## Updating Old Class Files

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.

## Other Enhancements

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.