These documentation pages are no longer current. They remain available for archival purposes. Please visithttps://docs.oracle.com/javase for the most up-to-date documentation.
Applet Developer's Guide > JavaPlug-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 theexecution of applets and interactions between applets and thebrowser.
With the next-generation Java Plug-in, the JRE no longer runsinside the browser. Instead, the JRE runs in a separateprocess. By default, all applets run in the same JRE instance.However, applets can now specify the JRE version they require torun on. More than one JRE instance will be launched when differentversions of the JRE are needed, or when the applet requires moreresources than any currently extant instance can supply.
The browser and the applet can still communicate with oneanother, however. Existing APIs have been re-engineered to useprocess sockets, so things continue to work as they didbefore--only better. This architecture provides a number ofbenefits:
With that architecture, a new JRE can be launched whenever it isneeded. 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 fromthe entries listed in the Java Control Panel ("Java" tab, "View"button under "Java Applet Runtime Settings"). The available JREs inthis list are encoded in thedeployment.propertiesfile whose location is platform-dependent. On the Windows platform,it is generally located inC:\Documents andSettings\[username]\Application Data\Sun\Java\Deployment. OnUnix platforms, it is generally located in~/.java/deployment/deployment.properties.
On Windows platforms, both the Java Control Panel and the newJava Plug-in will automatically detect the installed JREs and addthem to the available set. On Unix platforms, auto-detection ofinstalled JREs is not supported. The Java Applet Runtime Settingsdialog in the Java Control Panel may be used to manually add JREsto the known list for the new Java Plug-in.
By default the new Java Plug-in will execute all applets in thelatest JRE version named in this list. It will only execute anapplet on an earlier JRE version if explicitly requested.
When considering a request to launch an applet on a specific JREversion (for example, a particular update release like"1.5.0_11"):
When considering a request to launch an applet on a particularfamily, the most recent JRE from that family will be selected andthe above steps starting from (2) will be followed.
When considering a request to launch an applet on a particularfamily or any later family, the latest available JRE will be usedto launch the applet.
A web browser's JavaScript interpreter engine is single thread.The Java Plug-in is capable of managing multiple threads. The JavaPlug-in creates a separate worker thread for every applet. Appletsthemselves may be multi-threaded. Applets making JavaScript to Javacalls and vice versa, should be designed with the thread relatedissues in mind.
The following picture shows the thread interactions between theJavaScript Interpreter, Java Plug-in and an applet (i.e. Java).
When the JavaScript interpreter is idle, the Java Plug-inexecutes 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 JavaScriptto Java call is made, the latter is executed on the same threadthat made the Java to JavaScript call (Round Trip scenario).
When a thread is executing a Java to JavaScript call, anotherthread wanting to do the same will be blocked till the first threadhas received its result and is done (JavaScript Interpreter Busyscenario)
In order to avoid thread related issues especially when multipleapplets are running simultaneously, keep both Java to JavaScriptand JavaScript to Java calls short and avoid round trips, ifpossible.
Normally, if two applets have the samecodebase andarchive parameters, they will be loaded by the sameclass loader instance. This behavior is required for backwardcompatibility, and is relied on by several real-world applications.The result is that multiple applets on the same web page may accesseach others' static variables at the Java language level,effectively allowing the multiple applets to be written as thoughthey comprised a single application.
While this feature enables certain kinds of applications to beconveniently written, it has certain drawbacks. It interferes withtermination of applets, in particular when multiple instances ofthe same applet are active. It makes the programming model forapplets more complex, since it is under specified exactly when thestatic fields of an applet will be re-initialized, and when theywill be maintained from run to run of the same applet. It causesimprecise behavior of certain user interface operations within theJava Plug-in due to the inability to identify exactly which appletinitiated a particular request.
For this reason, the new Java Plug-in provides a way to opt outof the use of theclassloader cache onan applet by applet basis.
Garbage collection occurs on an applet instance immediatelyafter thedestroy method finishes. The garbagecollection applies to all memory acquired by the applet,exceptfor static variables . Statics are preserved in the classloadercache, along with the classes themselves, for as long as the classloader is present.
So when does the class loader go away? That behavior is notspecified. It's up to the implementation of the Java virtualmachine and its interactions with the operating system. You canexpect it be retained for as long as possible, but to be discardedwhen the memory is needed for other purposes.
An applet runs in a secure sandbox that prevents it frominteracting with the users system, unless authorized. To obtainthat authorization, the applet can provide asecuritycertificate that the user must accept. A security certificateis needed to:
The basic applet security model is an all or nothingproposition. If you get a security certificate, you can give theapplet full access to the user's system. Without it, the applet hasvirtually no access at all.
Deployment of applets using JNLP allows them to avail a morefine-grained security model (similar to Java Web Startapplications), that gives them controlled access to a user'ssystem, under control of the user. (For example, the ability tosave or open a file selected by the user and the ability toprint.)
SeeProxy Configuration in Java Deployment Guide fordetails.
SeeSecurity in Java Deployment Guide fordetails.
 |
