[RFC] PR858

[Deepak Bhole]

* Thomas Meyer <thomas at m3y3r.de> [2012-03-10 05:28]:
> Hello,
> 
> looking at bug 858 (e.g.
> http://www.chemaxon.com/marvin-archive/5.8.0/marvin/examples/applets/view/embed.html ) icedtea-web gets an NPE:
> 
> java.lang.NullPointerException
>     at
> net.sourceforge.jnlp.runtime.JNLPClassLoader.getPermissions(JNLPClassLoader.java:603)
>     at
> java.security.SecureClassLoader.getProtectionDomain(SecureClassLoader.java:210)
>     at
> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
>     at java.net.URLClassLoader.defineClass(URLClassLoader.java:277)
>     at java.net.URLClassLoader.access$000(URLClassLoader.java:73)
>     at java.net.URLClassLoader$1.run(URLClassLoader.java:212)
>     at java.security.AccessController.doPrivileged(Native Method)
>     at java.net.URLClassLoader.findClass(URLClassLoader.java:205)
>     at
> net.sourceforge.jnlp.runtime.JNLPClassLoader.findClass(JNLPClassLoader.java:1187)
>     at
> net.sourceforge.jnlp.runtime.JNLPClassLoader.loadClassExt(JNLPClassLoader.java:1214)
>     at
> net.sourceforge.jnlp.runtime.JNLPClassLoader.loadClass(JNLPClassLoader.java:1029)
>     at java.lang.Class.forName0(Native Method)
>     at java.lang.Class.forName(Class.java:186)
>     at chemaxon.marvin.applet.AppletLaunch.run(Unknown Source)
>     at java.lang.Thread.run(Thread.java:679)
> 
> This is because of:
> 
> 1.) the JNLPClassLoader constructor will only verify and add the jar
> "appletlauncher.jar" (only this jar will get a SecurityDesc entry), but
> will use the classpath defined in the manifest file, which contains all
> other "marvin" jars.
> 
> 2.) the AppletLaunch class will run next and tries to load another class
> from a jar in the classpath. this jar was not jet verified, i.e. has no
> SecurtiyDesc entry in the JNLPClassLoader.
> 
> 3.) the method JNLPClassLoader.loadClass(String name) has this code that
> looks like it should add jar files not yet verified, but this code will
> (as far as I understand) never be executed reached:
> 
>         // search this and the extension loaders
>         if (result == null) {
>             try {
>                 result = loadClassExt(name);
>             } catch (ClassNotFoundException cnfe) {
>                 // Not found in external loader either
> -> We never get here!

This is odd. The code was added in that catch because at one point
loadClassExt() was not automatically adding the index classes. Now it is
:/

The best thing would be to somehow remove the index from the JarFile
returned by CachedJarFileCallback, but entries cannot be removed without
re-writing the JAR. I think given that, your logic of check for sd looks
correct.

However, calling addJar means that the jar is now being downloaded twice
-- once by URLClassLoader (which doesn't cache it) and once by
JNLPClassLoader.

We could scan for INDEX.LIST beforhand and add those jars, but then that
defeats lazy loading. Other suggestions?

Deepak