[ForceRs]

I've created a test case that fails.

It fails with
Java Plug-in 1.6.0_15
Using JRE version 1.6.0_15-b03 Java HotSpot(TM) Client VM
and
Java Plug-in 1.6.0_18
Using JRE version 1.6.0_18-ea-b02 Java HotSpot(TM) Client VM

Please follow these instructions and let me know if it fails for you, too:
1) Close all browsers, ensuring that there are no plug-in coffee cup icons in the Windows taskbar.
2) Open the Java Control panel (Start->Control Panel->Java).
3) On the General tab, clear cache by clicking Settings..., Delete Files..., OK.
4) Open the Advanced tab.
5) Expand the Java Plug-in tree option.
6) Ensure that the "Enable the next-generation Java Plug-in" option is checked and click OK.
7) Visit page h t t p : // www . printdesktop . com/SignedAppletFails/SignedAppletFails.html
8) When presented with the allow applet to run dialog, check the "Always trust content from this publisher" checkbox.
9) The first page should load fine (SignedAppletFails.html).
10) From the main menu in the applet, click the Open_Window menu item and then click the "Top--reload page" sub-menu.
11) This should launch SignedAppletFails_New.html.
12) View the java console stacktrace. It should include a NullPointerException with reference to findAppletJDKLevel.

A few observations:
* Oddly, if you simply type "x" (clear classloader cache) on the java console, click the browser back button, and then choose "Open_Window->Top--reload page", the second applet runs fine.
* If you close the browser, wait for the coffee cup taskbar icon to go away, and immediately revisit the test page, all will work. It only happens when the disk cache is COMPLETELY empty.
* If you remove the certificate you accepted in step 8, and then perform the whole test again, but DO NOT check the "Always trust content from this publisher" checkbox, all will run fine.
* The jar file in this test case that I suspect is not being released (unlocked, whatever) by the first applet tear down is named SignedAppletFailsMisc.jar. The reason I believe SignedAppletFailsMisc.jar is being held is that if I were to create an identical file named SignedAppletFailsMisc2.jar and referenced SignedAppletFailsMisc2.jar in the second page, all would be fine.
* Again, It only happens when the disk cache is COMPLETELY empty.

I will submit the bug to sun after I receive some confirmation.

The problem (in this test case, at least), is that when the applet is signed, and the next-generation plug-in is enabled, and the JVM disk cache is completely empty, this error occurs.

The issue is that I have a common jar file that each applet references in the OBJECT applet tag. This is completely normal practice and is allowed. It seems that when the first applet is destroyed, it has some kind of lock on the jar file (SignedAppletFailsMisc.jar in this test), preventing the next applet launch from being able to use it.

Unfortunately, by default, this happens the very first time our web application is used (sign on and then redirect to another page that references a jar used in the sign on page). Meaning that the first thing a potential customer sees is a null pointer exception after logging in -- yikes!

The only workarounds I have thus far are to disable next-generation plug-in (testing for it in the sign on page), or, worst yet, supplying only one jar file per applet, each containing ALL of the classes required -- there is a lot of duplication of classes.