JOGL upgrade fails

I decided to upgrade my JOGL installation (which was working fine in Eclipse using b11-20101213) to the latest current release.  I cannot get it to work; I'm hoping someone can point out my problem (or at least suggest an approach).

I downloaded the 20111219 jogamp-windows-i586.7z and unzipped it.

I created a User Library pointing to each of the following jars located in the unzip location:  
- gluegen-rt.jar
- jogl.all.jar
- jogl-all-natives-windows-i586.jar

I added the \lib folder in the unzip location as the Native Library Location to each of the above three jars.

I'm under the impression that this should be all I need to do to run with the new (20111219) release.  However, when I run an application in Eclipse (one which worked fine using the b11-20101213 release) I get the following:

java.lang.UnsatisfiedLinkError: com.jogamp.common.os.Platform.getPointerSizeInBitsImpl()I

I have spent hours trying to figure out what is missing or what I've configured wrong.  Can anyone help?

Thanks.

Hi

You should not have to set the native library location in my humble opinion. Maybe look at the default settings of my own free open source projects, it works fine under any supported platforms and it works with Eclipse.

Just put jogl.all.jar and gluegen-rt.jar into the class path (Java build path in Eclipse) and put the JARs containing native libraries into the same directories and it should work. Good luck.

On 02/09/2012 04:18 PM, gouessej [via jogamp] wrote: Yup.

I guess it's time to remove the per platform archive files
in favor of the all-platform one.

Will keep the native libraries in there,
however we may remove it's reference from the wiki (howto, guides, etc)
or at least mark them as *alternative*. They cost lots of confusions.

I like to make a manual openjdk7 run on our platform,
if passed we are ready for RC6 I assume.

~Sven

I think your problem is that you're missing gluegen-rt-natives-windows-*.jar, which contains gluegen-rt.dll, which contains the native code for com.jogamp.common.os.Platform  You get the UnsatisfiedLinkError because JNI can't find the native code entry points without the .dll being loaded.

Just to be sure, I tried this just now with the latest dev build on Windows 7 64-bit with Eclipse Indigo, and it seems to work OK. I downloaded the gluegen and jogl .7z files for the 2012-02-09 development build, and extracted these four files into one directory:

gluegen-rt.jar
gluegen-rt-natives-windows-amd64.jar
jogl.all.jar
jogl-all-natives-windows-amd64.jar

I created a user library in Eclipse and added gluegen-rt.jar and jogl.all.jar to it (without setting the native library locations). Then I used the new user library in a test project, and sucessfully drew a triangle.

You're right Wade, he listed the JARs he uses, gluegen-rt-natives-windows-amd64.jar is missing.

Hi,
  First, thanks very much for all your responses; it's great that there is such immediate feedback on questions. Sorry it took me a couple of days to react; I spent a whole day trying to put all this together and then got sidetracked with Life.

Wade:  you were right -- as soon as I added the gluegen-rt-natives-xxx.jar to my Eclipse library (and then spent a bunch of time cleaning up Eclipse run configuration paths which still pointed to my old JOGL installation even though the Built Path pointed to the new installation) it worked great.  Thanks!

However, I'm confused about something.   In previous versions of JOGL, I had to add the location of the relevant lib directories (e.g. jogl and gluegen) to my PATH.  The procedure you described (and which works) doesn't include adding the .dlls to the PATH.  What I'm confused about is how the underlying system is finding those .dlls when they're not in the PATH.  Is there something magic (defined as: anything the user doesn't understand) about how Java processes .jar files (like gluegen-rt.jar) that causes it to look for .dlls in a jar in the the same location so that they don't need to be specified in the PATH?   (I do realize this is a bit off-topic but I'm trying to get a clearer picture of how it works so I can accurately pass it on to students in classes I'm teaching using JOGL...)

Sven:  regarding your comment about perhaps needing to go back to not having separate directories for each platform: I LIKE the fact that the build system separates those things out.  It makes it a little easier if one knows that all you need for your particular platform is contained in one place -- without the overhead and confusion of having other platform stuff there as well.  I've been using JOGL for a long time (much longer than my low-level questions would seem to imply; I started with 1.1 (that is, the 1.1 that preceded the first JSR version)  and have been using it ever since.  I even fooled around a little with gl4Java
.)  In all that time, no matter how great I think JOGL is (and I think it's wonderful), my biggest issue has been the difficulty involved it getting it running each time it changes.
I think anything you guys can do to simplify the process for those who aren't involved in the build aspects and don't necessarily understand the underlying architecture and system issues but just want to download and use the system is great.

Again, thanks to everyone for the help.

clevengr wrote

What I'm confused about is how the underlying system is finding those .dlls when they're not in the PATH.  Is there something magic (defined as: anything the user doesn't understand) about how Java processes .jar files (like gluegen-rt.jar) that causes it to look for .dlls in a jar in the the same location so that they don't need to be specified in the PATH?

The magic is, Sven added a new feature to JOGL  Previously, JOGL would simply do a System.loadLibrary() to load the native DLLs (this looks for DLLs in java.library.path, which the JVM sets up in a system-dependent way when you start it). Now what happens is, JOGL first looks at the path to the JAR file it's running from, then checks that directory to see if it contains "natives" JARs. If so, JOGL unpacks the DLLs from inside the "natives" JARs to a cache directory, then loads the DLLs from there instead of from the normal library path. If there are no "natives" JARs, JOGL just loads the DLLs the old way.

This is the same way SWT has worked for a long time. It lets the users avoid having to know about the DLL/SO/JNILIB files, so a library like JOGL that needs native code can appear to be a simple JAR like any other library.

One possible disadvantage of this system is that when you upgrade your JOGL JARs, the DLL caching system has to be smart enough to overwrite the old DLLs (but it can't just always overwrite them, since this would slow down startup times). There can also be problems finding a directory where the user has write permissions, depending on the OS and how the user permissions are set up. But once these problems are solved, it's a good system.

On 02/12/2012 10:02 PM, clevengr [via jogamp] wrote: It's the new magic as described here:

http://forum.jogamp.org/JogAmp-Deployment-Enhancements-Automatic-loading-of-native-JARs-Applet-Application-td3362447.html

The magic is implemented within Gluegen and all modules benefit from it now.
We use a semantic names 'os.and.arch' which is utilized at build- and runtime:
http://jogamp.org/jogl/doc/deployment/JOGL-DEPLOYMENT.html#NativeJARFileNameConvention

>
> Sven:  regarding your comment about perhaps needing to go back to not having
> separate directories for each platform: I LIKE the fact that the build
> system separates those things out.  It makes it a little easier if one knows
> that all you need for your particular platform is contained in one place --
> without the overhead and confusion of having other platform stuff there as
> well.  I've been using JOGL for a long time (much longer than my low-level
> questions would seem to imply;

Yup, the individual packages will be removed for RC6.
They - and the native library location etc .. are just a source of pain.

> I started with 1.1 (that is, the 1.1 that
> preceded the first JSR version)  and have been using it ever since.  I even
> fooled around a little with gl4Java

sweet .. yes it was fun doing gl4java back in the days.

> .)  In all that time, no matter how great I think JOGL is (and I think it's
> wonderful), my biggest issue has been the difficulty involved it getting it
> running each time it changes.
> I think anything you guys can do to simplify the process for those who
> aren't involved in the build aspects and don't necessarily understand the
> underlying architecture and system issues but just want to download and use
> the system is great.

Yup. The fun side here is of course changing the internals
to make it easier required a change :)

But hopefully after this 'native JAR loading' is established,
we can leave it as it is.

Trust me .. this change was floating around in our minds for a long time
and we hesitated to implement it.
The final kick was the simple requirement to allow JOGL Applets to be
started w/o JNLP .. simple as that. The positive side effects for
the normal desktop application and developers were just a consequence :)

>
> Again, thanks to everyone for the help.

You are very welcome.

~Sven

On 02/12/2012 10:26 PM, Wade Walker [via jogamp] wrote:
>
>
>
> One possible disadvantage of this system is that when you upgrade your JOGL
> JARs, the DLL caching system has to be smart enough to overwrite the old
> DLLs (but it can't just always overwrite them, since this would slow down
> startup times). There can also be problems finding a directory where the
> user has write permissions, depending on the OS and how the user permissions
> are set up. But once these problems are solved, it's a good system.

We have different levels of cache to consider here.

GlueGen Jar Cache:

The new cache with GlueGen I have added always starts from scratch
with a new JVM / ClassLoader, this is a requirement to native libraries
and it's classloader. We have a JVM level folder and within a classloader one.

The caches will be removed at startup when no lock is hold on it.

+++

Java (RT) Jar Cache (Network .. etc):

In case the base URL of the source of eg jogl.all.jar
is a network resource like http (Applets etc),
Java itself caches it and usually allows fast access
when the remote source has not changed.
However .. I have experienced a bug here (OS X I guess),
where the network cache returned an old JAR file.

+++

In conclusion I think our Jar Cache has no big side effects
or downsides. The same semantics was used within the AppletLauncher
and it worked quite well for a long time.

Wade and myself were able to fix a few 'odds' already.
Since it is already the default and 'in production' for a few month,
we haven't heard about complains so far.

~Sven

Well THAT explains a lot :)  Thanks!

I agree this is a much better scheme.  What is frustrating for me (and I suspect a lot of other users) is how hard it is to understand and keep up with the changes in the system(s).  (For example, the JOGL "User's Guide" hasn't been updated since the JSR 1.1 version).

I do know how hard it is to keep things updated, and I have great sympathy for the issues involved in generating documentation on volunteer projects (I have personal experience in that in another arena).
I greatly appreciate all the work the people in the JogAmp community do, and how fast responses are generated.

In case it is useful to anyone, here is my attempt to document at least a little bit of the process of using JOGL:
ftp://gaia.ecs.csus.edu/clevengr/165/handouts/JOGLv2.0Installation.pdf
(Comments and/or corrections are most welcome..)

Thanks for the help.

One more thing: am I correct in assuming that the JAR cacheing mechanism also applies to Linux and OS-X, so that it's no longer necessary to put the .so's in the LD_LIBRARY_PATH?

Thanks.

On 02/13/2012 12:50 AM, clevengr [via jogamp] wrote:
>
>
> One more thing: am I correct in assuming that the JAR cacheing mechanism also
> applies to Linux and OS-X, so that it's no longer necessary to put the .so's
> in the LD_LIBRARY_PATH?

yes, none is required or advocated anymore.

also - next version won't have platform archives anymore,
use the *all-platform* 7z archive.

you may also put the 'official' release URL into your 'handout'
jogamp-current .. -next .. etc, when you update it.

~Sven

>
> Thanks.