System.loadLibrary works in 1.3.1 but not in 1.2.2

Question

I Have a basic hello world application on Sun Solaris 7 that calls C++ from Java using JNI.
The code works well on 1.3.1, but when I recompile it under 1.2.2 and run I get the following exception when I call System.loadLibrary to load my shared library:
java.lang.UnsatisfiedLinkError: no MyLib in java.library.path
My LD_LIBRARY_PATH is set correctly since it worked under 1.3.1.
Just in case, I used the following code to get and set the java.library.path to no avail.
// Check System properties
String strLibPath = System.getProperty("java.library.path");
System.out.println("The Lib Path before set == " + strLibPath);
StringBuffer strLibPathBuffer = new StringBuffer("/u/kbonacc/mypath:");
strLibPathBuffer.append(strLibPath);
System.setProperty("java.library.path", strLibPathBuffer.toString());
strLibPath = System.getProperty("java.library.path");
System.out.println("The Lib Path after set == " + strLibPath);
Are there any differences between 1.3.1 and 1.2.2 in this respect?
Thanks,
-- Ken

Answer 1

In the bug parade I've heard excuses from Sun programmers that this is a read-only property and isn't supposed to be changed. It probably took them longer to write the reply to the bug than it would have to fix the code.
I looked at the source code for the ClassLoader and for the source release of the JDK 1.3.1 and here's the code I found in the ClassLoader.loadLibrary() method:
        if (sys_paths == null) {
                usr_paths = initializePath("java.library.path");
                sys_paths = initializePath("sun.boot.library.path");
        }It seems it parses and caches the system and user library paths on startup and then never bothers to check them to see if they've changed ever again. I think it would be pretty simple to rewrite that code block by moving one line of code down two lines as this:
        if (sys_paths == null) {
                sys_paths = initializePath("sun.boot.library.path");
        usr_paths = initializePath("java.library.path");I mean, it's not as if loadLibrary is really performance intensive or even critical enough to bother caching at all!
This one code change could fix a lot of headaches.
The particular headache I'm working on is that there doesn't seem to be any support in the Servlet 2.2 or 2.3 specification for JNI files. I'd really love to be able to use a directory like WEB-INF\jni to store libraries that need to be distributed with my web application. I tried to dynamically change java.library.path to include WEB-INF\jni, but alas I ran into the same problem you did, it doesn't work.
Is is possible for this to be fixed, ever? I think it would take longer to say no and make up a reason why not then it would to actually make the fix... seems a good enough arguement to do it to me.
And alternately, can we come up with a standard place to put JNI stuff for web applications in the next Servlet standards?
Thanks in advance!
-J.C.
[email protected]