I load an external library that is placed in ./lib
. Are these two solutions to set the java.library.path equivalent?
Set path in console when executing jar:
java -Djava.library.path=./lib -jar myApplication.jar
Set path in the code before loading library:
System.setProperty("java.library.path", "./lib");
If they are equivalent, why in the second solution can Java not find the library while the first one is ok?
If not, is there a way the set the path in the code?
The setProperty() method of Java system class sets the property of the system which is indicated by a key.
properties file located in users->appdata->locallow->sun->java>deployment and also directly putting key=value in runtime parameter in java control panel but not working. Edit: We use jeety server for deployment.
System properties are specified with command-line options in Java using the -Dname=value while environment variables are set in the operating system, using the EXPORT command in Unix and SET command in windows. To get a specific system property, we can use the System.
Although it is not well documented, the java.library.path
system property is a "read-only" property as far as the System.loadLibrary()
method is concerned. This is a reported bug but it was closed by Sun as opposed to getting fixed. The problem is that the JVM's ClassLoader reads this property once at startup and then caches it, not allowing us to change it programatically afterward. The line System.setProperty("java.library.path", anyVal);
will have no effect except for System.getProperty()
method calls.
Luckily, someone posted a workaround on the Sun forums. Unfortunately, that link no longer works but I did find the code on another source. Here is the code you can use to work around not being able to set the java.library.path
system property:
public static void addDir(String s) throws IOException { try { // This enables the java.library.path to be modified at runtime // From a Sun engineer at http://forums.sun.com/thread.jspa?threadID=707176 // Field field = ClassLoader.class.getDeclaredField("usr_paths"); field.setAccessible(true); String[] paths = (String[])field.get(null); for (int i = 0; i < paths.length; i++) { if (s.equals(paths[i])) { return; } } String[] tmp = new String[paths.length+1]; System.arraycopy(paths,0,tmp,0,paths.length); tmp[paths.length] = s; field.set(null,tmp); System.setProperty("java.library.path", System.getProperty("java.library.path") + File.pathSeparator + s); } catch (IllegalAccessException e) { throw new IOException("Failed to get permissions to set library path"); } catch (NoSuchFieldException e) { throw new IOException("Failed to get field handle to set library path"); } }
WARNING: This may not work on all platforms and/or JVMs.
Generally speaking, both approaches have the same net effect in that the system property java.library.path
is set to the value ./lib
.
However, some system properties are only evaluated at specific points in time, such as the startup of the JVM. If java.library.path
is among those properties (and your experiment seems to indicate that), then using the second approach will have no noticeable effect except for returning the new value on future invocations of getProperty()
.
As a rule of thumb, using the -D
command line property works on all system properties, while System.setProperty()
only works on properties that are not only checked during startup.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With