A strange problem – a strange solution

Dear colleagues,

Here is information on a strange problem with Java3D that I have found after the publication of JDK7u25. I have found that some examples on my demo site cannot work and crash with stack trail like this:

Exception in thread "J3D-MasterControl-1" java.lang.NullPointerException
	at sun.plugin.net.protocol.jar.CachedJarURLConnection.getJarFileInternal(Unknown Source)
	at sun.plugin.net.protocol.jar.CachedJarURLConnection.getJarFile(Unknown Source)
	at com.sun.deploy.security.DeployURLClassPath$JarLoader.getJarFile(Unknown Source)
	at com.sun.deploy.security.DeployURLClassPath$JarLoader.access$1000(Unknown Source)
	at com.sun.deploy.security.DeployURLClassPath$JarLoader$1.run(Unknown Source)
	at java.security.AccessController.doPrivileged(Native Method)
	at com.sun.deploy.security.DeployURLClassPath$JarLoader.ensureOpen(Unknown Source)
	at com.sun.deploy.security.DeployURLClassPath$JarLoader.<init>(Unknown Source)
	at com.sun.deploy.security.DeployURLClassPath$JarLoader$4.run(Unknown Source)
	at java.security.AccessController.doPrivileged(Native Method)
	at com.sun.deploy.security.DeployURLClassPath$JarLoader.getResource(Unknown Source)
	at com.sun.deploy.security.DeployURLClassPath$JarLoader.getResource(Unknown Source)
	at com.sun.deploy.security.DeployURLClassPath.getResource(Unknown Source)
	at sun.plugin2.applet.Plugin2ClassLoader$2.run(Unknown Source)
	at java.security.AccessController.doPrivileged(Native Method)
	at sun.plugin2.applet.Plugin2ClassLoader.findClassHelper(Unknown Source)
	at sun.plugin2.applet.Applet2ClassLoader.findClass(Unknown Source)
	at sun.plugin2.applet.Plugin2ClassLoader.loadClass0(Unknown Source)
	at sun.plugin2.applet.Plugin2ClassLoader.loadClass(Unknown Source)
	at sun.plugin2.applet.Plugin2ClassLoader.loadClass0(Unknown Source)
	at sun.plugin2.applet.Plugin2ClassLoader.loadClass(Unknown Source)
	at sun.plugin2.applet.Plugin2ClassLoader.loadClass(Unknown Source)
	at java.lang.ClassLoader.loadClass(Unknown Source)
	at javax.media.j3d.Renderer.<init>(Renderer.java:85)
	at javax.media.j3d.MasterControl$8.run(MasterControl.java:976)
	at java.security.AccessController.doPrivileged(Native Method)
	at javax.media.j3d.MasterControl.createRenderer(MasterControl.java:971)
	at javax.media.j3d.MasterControl.sendRenderMessage(MasterControl.java:2741)
	at javax.media.j3d.MasterControl.handlePendingRequest(MasterControl.java:3038)
	at javax.media.j3d.MasterControl.doWork(MasterControl.java:2877)
	at javax.media.j3d.MasterControlThread.run(MasterControlThread.java:62)

Well, I cannot understand what a fundamental reason of this situation is, but I have found a workaround and want to share it. It has appeared that the crash occurs in the course of 3D drawing if the vecmath.jar library is not loaded still. So, I use the following workaround now:

a dummy command

Color3f color3d= new Color3f(0,0,0);

is to be inserted in the program before the 3D scene creation. This issue changes the behavior of the program.

See log file before (crash): before.txt.
See log file after the fix: after.txt.

Well, I don’t understand what is wrong with JDK7u25-40, but now we have a workaround at least.

P.S. The second issue linked with JDK7u25 is that Java checks the Codebase tag in the MANIFEST files now. All gluegen and jogl archives use the

Codebase: *.jogamp.org

value now and this is very uncomfortable for me, because one must change all values to the * string to provide work in local net (without access to external sites like *.jogamp.org). So, I wonder if this is a policy of the jogamp.org or just an unforeseeable consequence of JDK change. Could it be fixed in the future releases please?

Thank you,

Alexei

My fixed demo site: http://www.alexei-morozov-2012.narod.ru/

On 10/03/2013 08:32 PM, Alexei A. Morozov [via jogamp] wrote:
> Dear colleagues,
>
> Here is information on a strange problem with Java3D that I have found after
> the publication of JDK7u25.
7u40 is the current release now, below you mention it .. also affected.

> I have found that some examples on my demo site
> cannot work and crash with stack trail like this:
>
> Exception in thread "J3D-MasterControl-1" java.lang.NullPointerException
> at sun.plugin.net.protocol.jar.CachedJarURLConnection.getJarFileInternal(Unknown Source)
> at sun.plugin.net.protocol.jar.CachedJarURLConnection.getJarFile(Unknown Source)
..
> at sun.plugin2.applet.Plugin2ClassLoader.loadClass(Unknown Source)
> at java.lang.ClassLoader.loadClass(Unknown Source)
> at javax.media.j3d.Renderer.<init>(Renderer.java:85)
> at javax.media.j3d.MasterControl$8.run(MasterControl.java:976)
> at java.security.AccessController.doPrivileged(Native Method)
..
Pls try to issue a GLProfile.initSingleton() upfront to ensure all
GlueGen/JOGL related classes (and native JAR files) are loaded.
This should not be necessary .. but thats the only test I could make here ..
Surely some weird class-loading issue, maybe even JAR order in applet/jnlp.

> Well, I don’t understand what is wrong with JDK7u25-40, but now we have a
> workaround at least.

ah .. 7u40 is affected as well.
The reason is explained here:

https://jogamp.org/bugzilla/show_bug.cgi?id=758

" 'Codebase: *.jogamp.org' will prevent copying the signed jar files
  and survive a vulnerability deletion,
  i.e. if we delete our copy from the server it .. it's of no use anymore.
  Users would need to signed the jars to be used on their servers.

Yes, this is more like snake oil .. not real security...."

You cannot simply 'open' and change the MANIFEST of our _signed_ JAR files.
If this is possible, Oracle just won another price for a non-working security method.

We set the 'Codebase' tag of the produced JAR files while building
using the environment variable 'JOGAMP_JAR_CODEBASE'
Unix'ish:
  export JOGAMP_JAR_CODEBASE="Codebase: *.goethel.localnet"
Windows:
  set JOGAMP_JAR_CODEBASE=Codebase: *.goethel.localnet

.. which sets the ant property 'jogamp.jar.codebase',
which you also could set directly when invoking ant.

After build, you will need to sign your builds and publish them ..

Of course, you could also download our unsigned builds
and edit the 'Codebase' tag.
You may use a unix tool like 'sed' for such task, it's simple.
The latter would also allow you to relocate all other codebase related entries,
have a look at jogamp-scripting repo.

Cheers, Sven

>
> Thank you,
>
> Alexei
>
> My fixed demo site: http://www.alexei-morozov-2012.narod.ru/

I completely agree with Sven and I'm against re-purposing our JARs. If you need to get rid of the "Codebase" attribute, sign the JARs by yourself like me, you can even automatize this task with a build tool, I use Ant to do so.

Hi, Sven

> Pls try to issue a GLProfile.initSingleton() upfront to ensure all
> GlueGen/JOGL related classes (and native JAR files) are loaded.
> This should not be necessary .. but thats the only test I could make here ..

I have implemented your test. Well, the result is negative. The program creates a bit different log, but has the same terrible end. :)

Case 1:
// Color3f color3d= new Color3f(0,0,0);
log1.txt

Case 2:
GLProfile.initSingleton();
log2.txt

Case 3:
Color3f color3d= new Color3f(0,0,0);
log3.txt

Sincerely yours,

Alexei