Posted by Larry Tesler on Jun 03, 2016; 2:29pm
URL: https://forum.jogamp.org/J3D-JOGL-good-within-Eclipse-but-UnsatisfiedLinkError-as-standalone-tp4036783p4036788.html

Phil,

I don't think I would have diagnosed this problem correctly without your help.

> Often this is caused because your installation of Java has the java3D jar files installed into the extension folder (very > common on MacOS) and those jar files are loaded before anything on your class path.
>
> So the first step would be to open the jre/ext folder and see what's in there, probably this folder
>  C:\Users\tesllar\Desktop\BigOldVendor\BigOldApp\Development\Installer Development\NSIS\BigOldApp\jre\lib\ext\
>
> If there is any Java3D jar files in there then that's the issue.

All four j3d jars were there. I had thought it would be enough to remove all explicit references to them but I was wrong.
 
> The easiest thing to do is then delete the java3d jars (including vecmath.jar) from that folder and re-test.

*** QUESTION: Should I remove the four jars from the Eclipse project's jre\lib\ext and rebuild? ***

To test the idea quickly, I did not rebuild. All I did was to remove the jars from the built application's jre\lib\ext. Then I tried run.bat, which does this:

jre\bin\java -Djogamp.gluegen.UseTempJarCache=false -Djava.library.path=C:\Users\tesllar\workspace\JOGL\jogamp-all-platforms\lib\windows-amd64 -Xms256m -Xmx1024m -XX:+HeapDumpOnOutOfMemoryError -jar .\lib\BigOldApp.jar "%1"

Result:

Exception in thread "AWT-EventQueue-0" java.lang.NoClassDefFoundError: javax/media/j3d/Canvas3D
...
Caused by: java.lang.ClassNotFoundException: javax.media.j3d.Canvas3D
        at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
        at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
        at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
        ... 41 more

> However this is often not a solution if you are deploying to machines with a pre-installed JRE.

We bundle a tested JRE in the application. We have control over what's in ext.

> If you are unable to change the users ext folder you will need to either:
> A/ change to Java3D 1.7 where all package names have been altered to not match the legacy names.

"A" sounds appealing. I will look into it.

> B/ use something like -Djava.ext.dirs=.\none\ in your start up properties. Though this this you can't access any jar in > the ext folder and so you'd need to find what you use (if anything) and move it into your project (a good idea anyway).

The app uses several things in ext. Why is it a good idea to move them into the project? One downside: Whenever we release an app update with a different jre bundled, we'll have to repeat the surgery.

Thanks,

Larry