Next-generation plug-in 1.6 : ClassNotFoundException and not caching JARs

Question

Hi,
Since the introduction of the next-generation plug-in in Java 1.6.0_10, the applet I have used and developed for many years don't load anymore.
The situation is this : the Jars of this applet are embedded in a Lotus Notes database as Java resources, in order to be used in a particular form in my application. Note that this application is accessed via a Web browser through a Domino server and that this application requires a user authentication. If I try to open the form containing the applet while using a plug-in 1.6.0_10 or newer, with default parameters (cache and next-generation plug-in activated), here is the exceptions I get (here with plug-in 1.6.0_20) :
load : class mycompany/tools/Planner not found.
java.lang.ClassNotFoundException: mycompany.tools.Planner
     at sun.plugin2.applet.Applet2ClassLoader.findClass(Unknown Source)
     at java.lang.ClassLoader.loadClass(Unknown Source)
     at java.lang.ClassLoader.loadClass(Unknown Source)
     at sun.plugin2.applet.Plugin2ClassLoader.loadCode(Unknown Source)
     at sun.plugin2.applet.Plugin2Manager.createApplet(Unknown Source)
     at sun.plugin2.applet.Plugin2Manager$AppletExecutionRunnable.run(Unknown Source)
     at java.lang.Thread.run(Unknown Source)
Caused by: java.io.IOException: open HTTP connection failed:http://www.mycompany.com:80/test/database.nsf/46277DA0EF2790B0C12574040052D714/$FILE/mycompany/tools/Planner.class
     at sun.plugin2.applet.Applet2ClassLoader.getBytes(Unknown Source)
     at sun.plugin2.applet.Applet2ClassLoader.access$000(Unknown Source)
     at sun.plugin2.applet.Applet2ClassLoader$1.run(Unknown Source)
     at java.security.AccessController.doPrivileged(Native Method)
     ... 7 more
Exception : java.lang.ClassNotFoundException: mycompany.tools.PlannerBy reading a lot forums I found that a lot (really a lot) of people were experiencing the exact same issue, regardless of the type of server they used to host their applet. And unfortunately, only few answers were relevant to help me understand why I got this error...
By looking deeper in the documentation, I have found this [Applet Developer's guide|http://download.oracle.com/javase/6/docs/technotes/guides/jweb/applet/applet_dev_guide.html]. Here, it is written that one of the enhancement of the next-generation plug-in is that : "+... The JVM running the applet is isolated from the web browser at the operating system level. If something should go wrong while running the applet, or if an uncooperative applet refuses to shut down, the new Java Plug-in detects and handles the error condition gracefully; the Web browser is unaffected+".
I am not quite sure of what it really means, but I have started to think that my problem could be that, by running in a separate process than the one of the Web browser, loading the Jars will require an authentication on my server. To verify this hypothesis, I have changed the codebase of my applet, so the Jars are downloaded from another server where no user authentication is required. The good news is that my applet can now find the Jars and run as expected. The bad news is that none of the Jars are placed in the cache, which means that the Jars have to be downloaded each time I start a new session to work with my applet.
I have also tried to disable the "Use the next-generation plug-in" option in the Java control panel. In this case, everything is fine, too, and even the Jars are stored in the cache. The interesting thing is that afterwards, by enabling the "Use the next-generation plug-in" option again, the applet will load and run like a charm... because the Jars are in the cache and the class loader can find them! (I suspect that this case has been experienced by several people, answering on forum posts that they cannot reproduce the issue.)
Anyway, even if there is some workarounds to ensure it is possible to work with the latest versions of the plug-in, having to change the default options is not always easy or possible, depending of the environment. This applet that I am talking about is used by a lot of our customers and all have their internal policies and requirements regarding the Java configuration. If for some of them it will be possible to use a workaround, for others it will not. And this is a major problem to me.
As I said, a lot of people have experienced this issue. I hope that someone having a better understanding on how this next-generation plug-in works, will have a solution, or at least, will be able to explain what is wrong in this approach and if my suggestion regarding an authentication issue for the class loader make sense.
Any help will be greatly appreciated.
Philippe

Answer 1

Hi,
I was wrong in my approach.
My applet was implemented using the "<object>" tag and it seems that it was not the best way to address compatibility issues across all versions of the plug-in and all browsers.
So, I have finally found what I was looking for in this "[Java Rich Internet Applications Development and Deployment|http://download.oracle.com/javase/6/docs/technotes/guides/jweb/index.html]" guide. In this guide, it is recommended to use the "[Deployment Toolkit|http://download.oracle.com/javase/6/docs/technotes/guides/jweb/deployment_advice.html#deplToolkit]", based on a Javascript library containing everything needed to deploy your application as an applet or a Java Web Start application.
My application, deployed as an applet, now works like a charm.
I hope pointing on this Deployment Toolkit will also help others...
Philippe