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?
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.
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 :)
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