United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6618920 Plugin2 : Add classloader caching support to new Plug-in
JDK-6618920 : Plugin2 : Add classloader caching support to new Plug-in

Details
Type:
Enhancement
Submit Date:
2007-10-18
Status:
Closed
Updated Date:
2011-12-20
Project Name:
JDK
Resolved Date:
2007-10-31
Component:
deploy
OS:
generic,windows_xp
Sub-Component:
plugin
CPU:
x86,generic
Priority:
P2
Resolution:
Duplicate
Affected Versions:
6u5,6u10
Fixed Versions:
6u10

Related Reports
Duplicate:
Relates:
Relates:
Relates:
Relates:

Sub Tasks

Description
Due to requests from different customers and not break some of the existing applications,classloader caching support should be added to the new Plug-in model.
In the new plug-in's implementation of the class loader cache, it is essential to allow applets to opt out of the entire mechanism. The current thinking is to support a new parameter to the applet tag like
   classloader_cache=false
which would prevent the class loader cache from being consulted for that applet instance. For compatibility reasons, however, it seems increasingly likely that by default the class loader cache will have to be used.

                                    

Comments
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.
                                     
2007-10-25
SUGGESTED FIX

http://sa.sfbay.sun.com/projects/deployment_data/6u5/6618920.1
                                     
2007-10-30
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.
                                     
2007-10-30
EVALUATION

This bug is being marked as a duplicate of 6622332 for bookkeeping purposes and does not need to be re-verified independently. In the case of a regression please file a new bug.
                                     
2007-10-31



Hardware and Software, Engineered to Work Together