The JavaTM platform defines APIs for the execution of applets in web browsers. While browsers and other execution environments may vary, users have discovered how popular browsers behave. While no specification guarantees it, developers have learned that applets can communicate with one another through static data members.
To reduce confusion and guesswork, this page describes how HotJava Browser handles interapplet communication. This information is provided for applet developers who need information about how applets communicate with one another in HotJava Browser.
Note: This is not an official specification of the behavior of applet execution environments; other browsers may not exhibit exactly the same behavior.
public class StaticHolder { public String aStatic; }Do two applets share a copy of StaticHolder.aStatic, or do they have different copies?
In HotJava Browser, an applet's scope is determined by the codebase--the directory that holds the root of the tree where the .class files reside. The codebase is also the URL of the base of the applet. So, if the two applets have a common codebase, then they share a copy of StaticHolder.aStatic. If they come from different codebases, they each have a separate copy.
An applet's codebase may refer either to the site from which the HTML document containing the <APPLET> tag was loaded or to a different site. If the codebase refers to a different site, then the applet's permissions reflect those of the codebase. The archive parameter (the preferred way of specifying one or more jar files) does not affect the codebase.
This is the algorithm that determines an applet's codebase:
docbase := URL of document containing applet tag, less file name part if (applet has a codebase parameter) then value := the value of the codebase parameter; if value ends in ".jar", strip it off; codebase := new URL(docbase, value) else codebase := docbase fiThe state visible to an applet consists of:
plus
This means that an applet can access static data members of other applets, whether on the same browser page or not, provided that the two applets have the same codebase.
Applets on the same page may use the methods AppletContext.getApplet(String) and AppletContext.getApplets() to communicate with one another. These methods give references only to applets in the same document with the same codebase as the calling applet.
For the purposes of AppletContext.getApplets(), a document is tied to a single source file. Thus, a document containing a <FRAMESET> is one document, and each frame within the <FRAMESET> is a seperate document. If you want to enable applets in different frames to access each other via getApplets(), however, set the system property hotjava.security.getInterFrameApplets to true.
HotJava Browser may destroy an applet that is not on a visible page at any time. It tries not to destroy applets that are on visible pages, but it may need to do so under certain circumstances, such as very low memory.
For instance, if you visit page P and then navigate to another page, the HotJava Browser might destroy applets on page P. If you revisit page P (as with the Back button), and the applets are still alive, they simply receive an Applet.start() call. If HotJava Browser has had to destroy the applets, it creates new ones.
Cooperating applets may share a thread; for instance, if the first applet in a codebase spawns a daemon thread to do some useful work, and then several applets on different pages use that thread. In a well-behaved scenario, the last applet in a codebase makes sure that that thread terminates when the applet receives its destroy() notification.
If a group of applets fails to terminate a thread, the browser will terminate it forcibly. However, the browser will not terminate a thread when one or more applets might depend on it. The browser will terminate an applet thread only when there are no active applets in the codebase from which the thread was created.
The HotJava Browser threads policy is:
However, when two browser windows are visible and both contain applets from the same codebase, HotJava Browser must either flush both windows or flush neither of them if it is to maintain the same static state for applets in both windows. In this version of HotJava Browser, neither is reloaded; that is, when HotJava Browser reloads a page, it reloads the applets only if no other applets from the same codebase are visible.
In other words, the codebase controls the set of static state that an applet may access. If applets can share state, they can also share threads. For this reason, the browser terminates applet threads only when their codebase is not being used.
Copyright © Sun Microsystems, Inc.