java.lang.UnsatisfiedLinkError no *****.dll in java.library.path
Asked Answered
T

14

100

How can I load a custom dll file in my web application? I've tried the following:

  • Copied all required dlls in system32 folder and tried to load one of them in Servlet constructor System.loadLibrary
  • Copied required dlls into tomcat_home/shared/lib and tomcat_home/common/lib

All these dlls are in WEB-INF/lib of the web-application

Trews answered 10/9, 2009 at 7:19 Comment(0)
C
166

In order for System.loadLibrary() to work, the library (on Windows, a DLL) must be in a directory somewhere on your PATH or on a path listed in the java.library.path system property (so you can launch Java like java -Djava.library.path=/path/to/dir).

Additionally, for loadLibrary(), you specify the base name of the library, without the .dll at the end. So, for /path/to/something.dll, you would just use System.loadLibrary("something").

You also need to look at the exact UnsatisfiedLinkError that you are getting. If it says something like:

Exception in thread "main" java.lang.UnsatisfiedLinkError: no foo in java.library.path

then it can't find the foo library (foo.dll) in your PATH or java.library.path. If it says something like:

Exception in thread "main" java.lang.UnsatisfiedLinkError: com.example.program.ClassName.foo()V

then something is wrong with the library itself in the sense that Java is not able to map a native Java function in your application to its actual native counterpart.

To start with, I would put some logging around your System.loadLibrary() call to see if that executes properly. If it throws an exception or is not in a code path that is actually executed, then you will always get the latter type of UnsatisfiedLinkError explained above.

As a sidenote, most people put their loadLibrary() calls into a static initializer block in the class with the native methods, to ensure that it is always executed exactly once:

class Foo {

    static {
        System.loadLibrary('foo');
    }

    public Foo() {
    }

}
Chlorobenzene answered 10/9, 2009 at 7:24 Comment(7)
By putting all dlls in System32 and using System.loadLibrary("something") worked. I was doing System.loadLibrary("something.dll") earlier. Why cant it load all dlls from WEB-INF? I guess it loads all jars by default. What can I do to load these dlls from WEB-INF directly instead of System32/specify them in java.library.pathTrews
+1 for the 'use "bla" instead of "bla.dll" for loadLibrary() remark-- very useful when you have no clue what you are doing wrong.Martel
On my system (Linux & java7), I need a lib prefix. So System.loadLibrary("foo") needs libfoo.so.Idiographic
Thanks. It worked for me when I updated "PATH" for windows so that it contains folder having *.so file.Atlante
I could have sworn that OSX required blah.jnilib and Linux libblah.so. Well, two hours later, after numerous tries, I came to the conclusion that OSX does also require lib prefixAnamorphosis
@JovanPerovic Just wanted to let you know that you saved my day ! I was pulling my hair about a library on OSX not loading... and I found your comment by chance. Thanks man ! Should be an information made more prominent everywhere.Adjudge
@Idiographic Thanks for your linux input. That exactly was my problem, as the java.library.path lined up and was recognizedby the JVM correctly, yet the file could not be loaded as "librust", as my filename is "librust.so". Calling "loadLibrary("rust") solved my issue. :)Broomrape
D
18

Changing 'java.library.path' variable at runtime is not enough because it is read only once by JVM. You have to reset it like:

System.setProperty("java.library.path", path);
//set sys_paths to null
final Field sysPathsField = ClassLoader.class.getDeclaredField("sys_paths");
sysPathsField.setAccessible(true);
sysPathsField.set(null, null);

Please, take a loot at: Changing Java Library Path at Runtime.

Doykos answered 12/2, 2014 at 14:1 Comment(1)
I get WARNING: An illegal reflective access operation has occurred and Exception in thread "main" java.lang.ExceptionInInitializerError and also Caused by: java.lang.NullPointerException when I do this.Mike
C
11

The original answer by Adam Batkin will lead you to a solution, but if you redeploy your webapp (without restarting your web container), you should run into the following error:

java.lang.UnsatisfiedLinkError: Native Library "foo" already loaded in another classloader
   at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1715)
   at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1646)
   at java.lang.Runtime.load0(Runtime.java:787)
   at java.lang.System.load(System.java:1022)

This happens because the ClassLoader that originally loaded your DLL still references this DLL. However, your webapp is now running with a new ClassLoader, and because the same JVM is running and a JVM won't allow 2 references to the same DLL, you can't reload it. Thus, your webapp can't access the existing DLL and can't load a new one. So.... you're stuck.

Tomcat's ClassLoader documentation outlines why your reloaded webapp runs in a new isolated ClassLoader and how you can work around this limitation (at a very high level).

The solution is to extend Adam Batkin's solution a little:

   package awesome;

   public class Foo {

        static {
            System.loadLibrary('foo');
        }

        // required to work with JDK 6 and JDK 7
        public static void main(String[] args) {
        }

    }

Then placing a jar containing JUST this compiled class into the TOMCAT_HOME/lib folder.

Now, within your webapp, you just have to force Tomcat to reference this class, which can be done as simply as this:

  Class.forName("awesome.Foo");

Now your DLL should be loaded in the common classloader, and can be referenced from your webapp even after being redeployed.

Make sense?

A working reference copy can be found on google code, static-dll-bootstrapper .

Cataldo answered 6/11, 2012 at 0:23 Comment(1)
This answer is excellent for application servers and should have its own question as it is wasted on this question.Scornik
O
8

You can use System.load() to provide an absolute path which is what you want, rather than a file in the standard library folder for the respective OS.

If you want native applications that already exist, use System.loadLibrary(String filename). If you want to provide your own you're probably better with load().

You should also be able to use loadLibrary with the java.library.path set correctly. See ClassLoader.java for implementation source showing both paths being checked (OpenJDK)

Oreste answered 19/10, 2012 at 21:34 Comment(2)
Thanks. Using load is actually much easier and more intuitive IMHO. Couldn't get loadLibrary to work no matter what I did ...Selfconsequence
This solution doesn't work for libraries that load their own native libraries.Squeal
Z
8

In the case where the problem is that System.loadLibrary cannot find the DLL in question, one common misconception (reinforced by Java's error message) is that the system property java.library.path is the answer. If you set the system property java.library.path to the directory where your DLL is located, then System.loadLibrary will indeed find your DLL. However, if your DLL in turn depends on other DLLs, as is often the case, then java.library.path cannot help, because the loading of the dependent DLLs is managed entirely by the operating system, which knows nothing of java.library.path. Thus, it is almost always better to bypass java.library.path and simply add your DLL's directory to LD_LIBRARY_PATH (Linux), DYLD_LIBRARY_PATH (MacOS), or Path (Windows) prior to starting the JVM.

(Note: I am using the term "DLL" in the generic sense of DLL or shared library.)

Zurek answered 17/1, 2014 at 15:33 Comment(0)
J
5

If you need to load a file that's relative to some directory where you already are (like in the current directory), here's an easy solution:

File f;

if (System.getProperty("sun.arch.data.model").equals("32")) {
    // 32-bit JVM
    f = new File("mylibfile32.so");
} else {
    // 64-bit JVM
    f = new File("mylibfile64.so");
}
System.load(f.getAbsolutePath());
Jilolo answered 13/7, 2013 at 17:40 Comment(0)
H
4

For those who are looking for java.lang.UnsatisfiedLinkError: no pdf_java in java.library.path

I was facing same exception; I tried everything and important things to make it work are:

  1. Correct version of pdf lib.jar ( In my case it was wrong version jar kept in server runtime )
  2. Make a folder and keep the pdflib jar in it and add the folder in your PATH variable

It worked with tomcat 6.

Hydro answered 31/8, 2012 at 12:18 Comment(0)
R
4

The issue for me was naming:

The library name should begin with "lib..." such as libnative.dll.

So you might think you need to load "libnative": System.loadLibrary("libnative")

But you actually need to load "native": System.loadLibrary("native")

Rancher answered 24/4, 2022 at 5:52 Comment(0)
T
3
  1. If you believe that you added a path of native lib to %PATH%, try testing with:

    System.out.println(System.getProperty("java.library.path"))
    

It should show you actually if your dll is on %PATH%

  1. Restart the IDE Idea, which appeared to work for me after I setup the env variable by adding it to the %PATH%
Toothy answered 29/10, 2018 at 11:16 Comment(0)
A
2

Poor me ! spent a whole day behind this.Writing it down here if any body replicates this issue.

I was trying to load as Adam suggested but then got caught with AMD64 vs IA 32 exception.If in any case after working as per Adam's(no doubt the best pick) walkthrough,try to have a 64 bit version of latest jre.Make sure your JRE AND JDK are 64 bit and you have correctly added it to your classpath.

My working example goes here:unstatisfied link error

Apocalypse answered 19/10, 2012 at 21:7 Comment(0)
C
2

I'm using Mac OS X Yosemite and Netbeans 8.02, I got the same error and the simple solution I have found is like above, this is useful when you need to include native library in the project. So do the next for Netbeans:

1.- Right click on the Project
2.- Properties
3.- Click on RUN
4.- VM Options: java -Djava.library.path="your_path"
5.- for example in my case: java -Djava.library.path=</Users/Lexynux/NetBeansProjects/NAO/libs>
6.- Ok

I hope it could be useful for someone. The link where I found the solution is here: java.library.path – What is it and how to use

Crystallization answered 31/3, 2015 at 2:47 Comment(2)
Hi Alex, I have a question here is there any problem if the library path includes some spacing in the path in this line VM Options: java -Djava.library.path="your_path"Stripper
Mmm I'm not working with Java for the last year but as conflicts may appear I recommend avoid from adding empty spaces in the file path.Crystallization
A
1

It is simple just write java -XshowSettings:properties on your command line in windows and then paste all the files in the path shown by the java.library.path.

Anaya answered 31/7, 2019 at 17:20 Comment(0)
E
0

I had the same problem and the error was due to a rename of the dll. It could happen that the library name is also written somewhere inside the dll. When I put back its original name I was able to load using System.loadLibrary

Energetics answered 4/10, 2018 at 12:50 Comment(0)
L
0

First, you'll want to ensure the directory to your native library is on the java.library.path. See how to do that here. Then, you can call System.loadLibrary(nativeLibraryNameWithoutExtension) - making sure to not include the file extension in the name of your library.

Libertylibia answered 17/9, 2020 at 20:23 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.