EVALUATION
Added support to new Java Plug-In for caching of class loaders,
enabled by default, for compatibility with existing applet content, in
particular games from www.pogo.com.
The semantics of the class loader cache are unchanged from the old
plug-in. If two applets come from the same code base, and have the
same archive tag, they will be loaded by the same class loader. This
allows these applets to see each others' static variables.
As long as at least one applet loaded by a particular class loader is
active, its AppContext and ThreadGroup will persist. Once all applets
loaded by a particular class loader have been stopped, the ThreadGroup
and AppContext are disposed. The class loader may be reused after this
point if garbage collection does not reclaim it. Again, these are the
same semantics as in the old plug-in.
The introduction of the class loader cache causes problems with the
handling of modal dialogs. We were previously relying on being able to
precisely determine which applet popped up a modal dialog by virtue of
one applet being loaded in each AppContext. Now that more than one
applet can be loaded in the same AppContext, we are not always able to
determine which browser-side plug-in instance should block the
browser. This means that a given applet's modal dialog might block the
wrong browser window. It is not clear how best to resolve this
problem. We may need to add code to block more than one browser window
while a Java modal dialog is active, unless we can devise a better
solution. 6621874 has been filed to track this issue and will be fixed
separately.
On the request of the JavaFX team, a mechanism to opt out of using the
class loader cache on a per-applet basis has been introduced.
Specifying "classloader_cache=false" in the applet tag or as a
parameter will prevent the use of the class loader cache for that
applet instance and therefore the abovementioned problem as well as
others.
Compared to the old one, the new class loader cache has been
restructured for maximum code reuse and separation of concerns. The
cache itself is responsible only for managing the caching of the class
loaders, AppContexts and ThreadGroups. The creation and destruction of
these objects is still the responsibility of the Applet2Manager. While
there are large sets of changes in the Applet2Manager, these mostly
move around and refactor code rather than introduce new code.
Note that this set of changes is not sufficient to make the Pogo games
run; the fix for 6617302, to be checked in separately, is also required.
|
EVALUATION
The new implementation of the class loader cache has been built and tested with games from Pogo. More testing is needed, and the engineering is not quite finished, but the implementation appears to be working and satisfies the requirement that individual applets can opt out of using it by passing the "classloader_cache=false" parameter to the applet.
|
Java