Running natives from JARs

Hello,

I've noticed that JogAmp products ships with JARs with names like gluegen-rt-natives-linux-amd64.jar Inside there's libgluegen-rt.so I think you're made them so we could load native libraries without the use of java.library.path VM parameter. However, I've deleted that parameter from NetBeans run configuration and added those JARs to classpath, but then JOCL complained about lack of JOCL native libraries. How could I manage to use JOCL without java.library.path parameter and "naked" native libraries?

Hi,

classpath libloading is not yet supported but we had it on our todo list already. The jvm only supports loading libs from filesystem. To fake classpath libloading we would have to extract them to a temp directory and load them from there.

-michael

What a pity. I thought JVM has some special built-in constructs to load natives.

Such fake classpath libloading probably has even less use than normal folders when we want to use JOCL in applets? I am right?

yes you are right, for applets you won't need that usually. It would be more interesting for lowering the barrier to get started with jocl however ("just put everything in the classpath and you are done").

You can use jnlps for the applet in the same way you would setup a webstart application. It won't work with old java installations but the experience of running java 5 or older in the browser is not that good anyway :)

for an example take a look at the CLInfo jnlp file at:
http://jogamp.org/jocl-demos/www/

all you have to do is to add this jnlp extension and the right libraries are chosen for you automatically.

<extension href="http://jogamp.org/deployment/webstart-next/jocl.jnlp" name="jocl"/>

(of course you can host the extension jnlp on your server if you like)

SWT does this sort of "classpath libloading". The SWT startup code looks at the value of java.library.path, and extracts the SWT .dll/.so/.jnilib files to one of those paths that the JVM is already looking at. Then subsequent System.loadLibrary() calls will work properly, and the user doesn't have to see any .dll/.so/.jnilib at all.

This is a bit tricky, because they have to put version numbers in the .dll/.so/.jnilib filenames to keep SWT apps with different versions from conflicting with each other. They also have a particular order that they try these paths in, since on some systems the library paths aren't writable by the user.

As far as I know, this is a limitation of the OSes, not Java -- operating system functions to load dynamic libraries always seem to take file paths, not streams