| Documentation Contents |
Applet Developer's Guide > Java Plug-in and Applet Architecture
Contents
This document describes how the next-generation Java Plug-in, introduced in the Java SE 6 update 10 release, controls the execution of applets and interactions between applets and the browser.
With the next-generation Java Plug-in, the JRE no longer runs inside the browser. Instead, the JRE runs in a separate process. By default, all applets run in the same JRE instance. However, applets can now specify the JRE version they require to run on. More than one JRE instance will be launched when different versions of the JRE are needed, or when the applet requires more resources than any currently extant instance can supply.
The browser and the applet can still communicate with one another, however. Existing APIs have been re-engineered to use process sockets, so things continue to work as they did before--only better. This architecture provides a number of benefits:
With that architecture, a new JRE can be launched whenever it is needed. But an applet will run in an existing JRE as long as:
Note:
On all platforms, the new Java Plug-in locates JREs to use from
the entries listed in the Java Control Panel ("Java" tab, "View"
button under "Java Applet Runtime Settings"). The available JREs in
this list are encoded in the deployment.properties
file whose location is platform-dependent. On the Windows platform,
it is generally located in C:\Documents and
Settings\[username]\Application Data\Sun\Java\Deployment. On
Unix platforms, it is generally located in
~/.java/deployment/deployment.properties.
On Windows platforms, both the Java Control Panel and the new Java Plug-in will automatically detect the installed JREs and add them to the available set. On Unix platforms, auto-detection of installed JREs is not supported. The Java Applet Runtime Settings dialog in the Java Control Panel may be used to manually add JREs to the known list for the new Java Plug-in.
By default the new Java Plug-in will execute all applets in the latest JRE version named in this list. It will only execute an applet on an earlier JRE version if explicitly requested.
When considering a request to launch an applet on a specific JRE version (for example, a particular update release like "1.5.0_11"):
When considering a request to launch an applet on a particular family, the most recent JRE from that family will be selected and the above steps starting from (2) will be followed.
When considering a request to launch an applet on a particular family or any later family, the latest available JRE will be used to launch the applet.
A web browser's JavaScript interpreter engine is single thread. The Java Plug-in is capable of managing multiple threads. The Java Plug-in creates a separate worker thread for every applet. Applets themselves may be multi-threaded. Applets making JavaScript to Java calls and vice versa, should be designed with the thread related issues in mind.
The following picture shows the thread interactions between the JavaScript Interpreter, Java Plug-in and an applet (i.e. Java).
When the JavaScript interpreter is idle, the Java Plug-in executes a JavaScript to Java call on the per applet worker thread (JavaScript Interpreter Not Busy scenario).
When a Java to Javascript call is in progress and a JavaScript to Java call is made, the latter is executed on the same thread that made the Java to JavaScript call (Round Trip scenario).
When a thread is executing a Java to JavaScript call, another thread wanting to do the same will be blocked till the first thread has received its result and is done (JavaScript Interpreter Busy scenario)
In order to avoid thread related issues especially when multiple applets are running simultaneously, keep both Java to JavaScript and JavaScript to Java calls short and avoid round trips, if possible.
Normally, if two applets have the same codebase and
archive parameters, they will be loaded by the same
class loader instance. This behavior is required for backward
compatibility, and is relied on by several real-world applications.
The result is that multiple applets on the same web page may access
each others' static variables at the Java language level,
effectively allowing the multiple applets to be written as though
they comprised a single application.
While this feature enables certain kinds of applications to be conveniently written, it has certain drawbacks. It interferes with termination of applets, in particular when multiple instances of the same applet are active. It makes the programming model for applets more complex, since it is under specified exactly when the static fields of an applet will be re-initialized, and when they will be maintained from run to run of the same applet. It causes imprecise behavior of certain user interface operations within the Java Plug-in due to the inability to identify exactly which applet initiated a particular request.
For this reason, the new Java Plug-in provides a way to opt out of the use of the classloader cache on an applet by applet basis.
Garbage collection occurs on an applet instance immediately
after the destroy method finishes. The garbage
collection applies to all memory acquired by the applet, except
for static variables . Statics are preserved in the classloader
cache, along with the classes themselves, for as long as the class
loader is present.
So when does the class loader go away? That behavior is not specified. It's up to the implementation of the Java virtual machine and its interactions with the operating system. You can expect it be retained for as long as possible, but to be discarded when the memory is needed for other purposes.
An applet runs in a secure sandbox that prevents it from interacting with the users system, unless authorized. To obtain that authorization, the applet can provide a security certificate that the user must accept. A security certificate is needed to:
The basic applet security model is an all or nothing proposition. If you get a security certificate, you can give the applet full access to the user's system. Without it, the applet has virtually no access at all.
Deployment of applets using JNLP allows them to avail a more fine-grained security model (similar to Java Web Start applications), that gives them controlled access to a user's system, under control of the user. (For example, the ability to save or open a file selected by the user and the ability to print.)
See Proxy Configuration in Java Deployment Guide for details.
See Security in Java Deployment Guide for details.
Copyright © 1993, 2010, Oracle and/or its affiliates. All rights reserved. Please send comments using this Feedback page. |
 Java Technology |