Posted by Larry Tesler on Jun 02, 2016; 8:57pm
URL: https://forum.jogamp.org/J3D-JOGL-good-within-Eclipse-but-UnsatisfiedLinkError-as-standalone-tp4036783.html

I maintain a huge Windows 7 standalone application I'll call "BigOldApp". A tested JRE is bundled with the product. I recently upgraded the environment from 32-bit Java 6 to 64-bit Java 7. I migrated a 3D graphics feature from 32-bit to 64-bit Java3D using JogAmp's Java3D pre12 + JOGL 2.3.2 + Gluegen 2.3.2.

I created an Eclipse project named JOGL as suggested in the documentation. I included source code just for debugging purposes. Because an IT security policy regarding temporary files caused Automated Native Library Loading to crash, I gave up on automation and got the application working inside Eclipse by adding:

        -Djogamp.gluegen.UseTempJarCache=false
        -Djava.library.path=C:\Users\myname\workspace\JOGL\jogamp-all-platforms\lib\windows-amd64

to VM args and by setting the native library locations of gluegen-rt and jogl-all to

        JOGL/jogamp-all-platforms/jar/atomic

BigOldApp only calls Java3D if and when the user invokes the 3D feature.

It works like a charm. Inside Eclipse, that is.

Next, I ran MyApp's legacy ANT script to consolidate code from three legacy Eclipse projects plus the bundled Java plus the newly added JOGL:

        BigOldApp
        BigOldLib
        BigOldImporter
        JRE
        JOGL

I will run an existing installer soon using NSIS but first I want to prove that ANT did the right thing.

The legacy Ant scripts built a directory hierarchy at the top level of the Eclipse workspace. Among other things, this directory contains:

        BigOldApp.exe
        BigOldApp.bat
        lib
           BigOldApp.jar

The app launched but the 3D feature crashed with:

Exception in thread "AWT-EventQueue-0" java.lang.
UnsatisfiedLinkError: C:\Users\tesllar\Desktop\BigOldVendor\BigOldApp\Development\Installer Development\NSIS\BigOldApp\jre\bin\J3D.dll: Can't load a 32-bit .dll on a AMD 64-bit platform
        at java.lang.ClassLoader$NativeLibrary.load(Native Method)
        at java.lang.ClassLoader.loadLibrary1(ClassLoader.java:1965)
        at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1890)
        at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1872)
        at java.lang.Runtime.loadLibrary0(Runtime.java:849)
        at java.lang.System.loadLibrary(System.java:1088)
        at javax.media.j3d.MasterControl$22.run(MasterControl.java:889)
        at java.security.AccessController.doPrivileged(Native Method)
        at javax.media.j3d.MasterControl.loadLibraries(MasterControl.java:886)
        at javax.media.j3d.VirtualUniverse.<clinit>(VirtualUniverse.java:229)

I added the recommended VM ARGS to the batch file but it made no difference.

I added no code to the legacy Ant scripts or JOGL's barebones Ant scripts. Is that why it grabbed a 32-bit dll instead of the requested 64-bit version? What's the recommended way to integrate Ant processing into a Java3D+JOGL build process?

Thanks,

Larry Tesler