[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Help-glpk] Slight problem with JNI library loading code
From: |
Chris Wolf |
Subject: |
[Help-glpk] Slight problem with JNI library loading code |
Date: |
Fri, 19 Mar 2010 15:26:50 -0400 |
User-agent: |
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 |
Xypron,
Currently the JNI library loader code looks like:
static {
try {
// try to load Linux library
System.loadLibrary("glpk_java");
} catch (UnsatisfiedLinkError e) {
// try to load Windows library
System.loadLibrary("glpk_4_43_java");
}
}
The problem with this code is that if it fails to load "glpk_java" it
will always try to load "glpk_4_43_java" next, even though this name
appears to be for Windows only. The reason this is a problem is that
"glpk_java" could fail to load for reasons other then that it's not
on the java.library.path or doesn't exist. For example, on MacOS,
if the library exists and is on the java.library.path, but has the
incorrect architecture, it will throw an UnsatisfiedLinkError, but
the stack trace will incorrectly attribute this to "glpk_4_43_java".
In any case, it's a best practice to avoid using exceptions for non-exceptional
logic, such as the conditional case here. I'd like to recommend
changing the code to something like this:
static {
if (System.getProperty("os.name").startsWith("Windows")) {
// try to load Windows library
System.loadLibrary("glpk_4_43_java");
} else {
// try to load POSIX library
System.loadLibrary("glpk_java");
}
I assume the reason you have a different base name for the Windows library
is because you were unable to put version information in the library, otherwise,
I'm not sure why it can't have the same base name since the base name is
supposed to be platform-independent.
Thanks,
-Chris