JDK-6618920 : Plugin2 : Add classloader caching support to new Plug-in
  • Type: Enhancement
  • Component: deploy
  • Sub-Component: plugin
  • Affected Version: 6u5,6u10
  • Priority: P2
  • Status: Closed
  • Resolution: Duplicate
  • OS: generic,windows_xp
  • CPU: generic,x86
  • Submitted: 2007-10-18
  • Updated: 2011-12-20
  • Resolved: 2007-10-31
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 6
6u10Resolved
Related Reports
Duplicate :  
JDK-6622332 - Initial integration of new Java Plug-In
Relates :  
JDK-6621874 - Modal dialog blocking of browser imprecise with introduction of class loader cache
Relates :  
JDK-6627386 - JavaScript errors with gamehouse.com applets
Relates :  
JDK-6626774 - Plugin2: ClassLoader cache leak if the applet fails to load some class
Relates :  
JDK-6617302 - pogo game applets fail to load
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 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.
31-10-2007
SUGGESTED FIX http://sa.sfbay.sun.com/projects/deployment_data/6u5/6618920.1
30-10-2007
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.
30-10-2007
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.
25-10-2007