Develop Reference

java.lang.UnsatisfiedLinkError: no JMagick in java.library.path

Has anyone used JMagick? I imported the jar using maven and got error "java.lang.UnsatisfiedLinkError: no JMagick in java.library.path". After lot of research, I found that I should set the path of libJMagick.so file in java.library.path. http://www.jmagick.org/6.4.0/ only has the sourcecode of jmagick. I tried following the instructions here (https://gist.github.com/kei2100/4688805) to build jmagick. I'm stuck at below line
./configure --with-java-home=/System/Library/Frameworks/JavaVM.framework/Versions/Current --with-magick-home=/usr/local/Cellar/imagemagick/6.7.1-1/
It keeps failing with error "configure: error: 'Unable to locate jni.h'" I have jni.h under my java_home/include folder. I tried passing include folder using --with-java-includes argument. But it still keeps failing. Any idea how to move forward?

As stated here, you have to specify the JDK include paths as compiler flag, e.g.:
./configure CPPFLAGS="-I$JAVA_HOME/include -I$JAVA_HOME/include/linux" --with-java-home=$JAVA_HOME --with-magick-home=/usr/local/Cellar/imagemagick/6.7.1-1/
Alternatively you can also create a file named config.site and specify the compiler flags there (as stated here).

DLL Load Library Error in Java Eclipse

I want to use DLL for FiscalPrinter, i placed the empifis.dll inside jre6/bin folder and called the DLL code in Java program as below,
CLibrary INSTANCE = (CLibrary)Native.loadLibrary("empifis", CLibrary.class);
It throws the error :
Exception in thread "main" java.lang.UnsatisfiedLinkError: Unable to load library 'empifis': The specified module could not be found.
at com.sun.jna.NativeLibrary.loadLibrary(NativeLibrary.java:145)
at com.sun.jna.NativeLibrary.getInstance(NativeLibrary.java:188)
at com.sun.jna.Library$Handler.<init>(Library.java:123)
at com.sun.jna.Native.loadLibrary(Native.java:255)
at com.sun.jna.Native.loadLibrary(Native.java:241)
at org.compiere.pos.Main$CLibrary.<clinit>(Main.java:15)
at org.compiere.pos.Main.main(Main.java:35)

Maybe you need to provide the file extension .dll?
You can btw also put it in the system folder where most of the dlls are stored. Or you add a path to the environment variables.

Add dll to ClassPath
I think this is what you are looking for

JPL/SWI Prolog configuration failure

I'm configuring the JPL right now, and wanna work with swi-prolog using java.
I downloaded the newest stable version of SWI-Prolog, which is 6.2.0, and installed in D:\swipl
First, I added the following path to the PATH virable: D:\swipl\bin, which should include all dll files needed.
Then, I added the following path to the CLASSPATH virable: D:swipl\lib\jpl.jar, which should be the jar file needed.
When I tried to run the versions example provided, I got the following error:
Exception in thread "main" java.lang.UnsatisfiedLinkError: jpl.fli.Prolog.thread_self()I
at jpl.fli.Prolog.thread_self(Native Method)
at jpl.Query.open(Query.java:286)
at jpl.Util.textToTerm(Util.java:162)
at jpl.Query.Query1(Query.java:183)
at jpl.Query.<init>(Query.java:176)
at Versions.main(Versions.java:11)
After searching online, I found that many people just get java.lang.UnsatisfiedLinkError: no jpl in java.library.path which is because of the setting for the PATH variable, rather than the error I get here: java.lang.UnsatisfiedLinkError: jpl.fli.Prolog.thread_self()I (and yes, there is a "I" at the end of the line).
Has anyone gotten this error before? I've tried several previous version of SWI-Prolog, but also got other kinds of errors. I'm using Eclipse IDE for Java development -- have I missed anything?

I've sent the problem to the official mailing list (swi-prolog#lists.iai.uni-bonn.de) provided by swi-prolog.org, and luckily someone helped me to prove that there are some problems in the version 6.2.0. We then both tried the version 6.0.2, and it works perfectly. He mentioned that (and I noticed that) there is no swipl.dll in the bin folder of the version 6.2.0, which MAY causes the issue.
I've already reported the issue to the staff via Email, and at least for now, I suggest that people who want to configure JPL should download the version 6.0.2. Three things to remember:
add a new variable SWI_HOME_DIR under system variables in environment variables, and set the path to the place where you installed the SWI-Prolog (Mine is D:\swipl);
Add the path %SWI_HOME_DIR%\bin to your PATH variable, rather than use something like "D:\swipl\bin". (Otherwise [FATAL ERROR: Could not find system resources] will occur)
Add the path %SWI_HOME_DIR%\lib\jpl.jar to your PATH variable, rather than use something like "D:\swipl\lib\jpl.jar". (Otherwise [FATAL ERROR: Could not find system resources] will occur)
If you are using Eclipse for Java development, it seems that you DO NOT need to configure in your IDE. As long as you follow the 3 steps above and add the correct jar file as an external library, it should be fine.
I'm not sure whether the temporary solution works for everyone, but definitely, everyone who has the issue should try this method first. As long as the issue in the version 6.2.0 has been figured out, I'll add some comments here.
BTW, as far as I know, until now, people who have the issue are using 32-bit Windows.

Try adding your path to java.library.path via Run > Run Configuration > [project name] and add the following under "VM Arguments" tab.
-Djava.library.path="D:\swipl\bin;."
Furthermore, under the "Environment" tab, add the following:
VARIABLE: PATH
VALUE: D:\swipl\bin;${env_var:PATH}
After that, go to Project > Properties > Java Build Path, select "Libraries" tab.
Click "Add External JARS.." and find your jpl.jar.

Great Great Great, second answer is the solution
create SWI_HOME_DIR variable to set the swi prolog instalation directory
SWI_HOME_DIR ------- C:\Program Files\swipl
set PATH to point to the library and bin like this
PATH ------ %SWI_HOME_DIR%\bin;%SWI_HOME_DIR%\lib\jpl.jar
This fix my problem "Exception in thread "main" java.lang.UnsatisfiedLinkError: no jpl in java.library.path windows" it is a little bit rare but it works find.

I had the same problem. In addition to set the PATH, you need to verify if the installed SWI program has the same architecture (32 or 64) of your JVM.

Trying to Use ESAPI But getting Error

I am trying to use ESAPI.jar for providing security to my web application.Basically I have just started using ESAPI.jar.
But problem is I am not able to run even a simple program using ESAPI.
The small code snippet is:
String clean = ESAPI.encoder().canonicalize("someString");
Randomizer r=ESAPI.randomizer();
System.out.println(r);
System.out.println(clean);
I get this error:
Attempting to load ESAPI.properties via file I/O.
Attempting to load ESAPI.properties as resource file via file I/O.
Not found in 'org.owasp.esapi.resources' directory or file not readable: D:\Eclipse-Workspace\Test\ESAPI.properties
Not found in SystemResource Directory/resourceDirectory: .esapi\ESAPI.properties
Not found in 'user.home' (C:\Documents and Settings\user.user) directory: C:\Documents and Settings\user.user\esapi\ESAPI.properties
Loading ESAPI.properties via file I/O failed. Exception was: java.io.FileNotFoundException
Attempting to load ESAPI.properties via the classpath.
ESAPI.properties could not be loaded by any means. Fail. Exception was: java.lang.IllegalArgumentException: Failed to load ESAPI.properties as a classloader resource.
Exception in thread "main" org.owasp.esapi.errors.ConfigurationException: java.lang.reflect.InvocationTargetException SecurityConfiguration class (org.owasp.esapi.reference.DefaultSecurityConfiguration) CTOR threw exception.
at org.owasp.esapi.util.ObjFactory.make(ObjFactory.java:129)
at org.owasp.esapi.ESAPI.securityConfiguration(ESAPI.java:184)
at org.owasp.esapi.ESAPI.encoder(ESAPI.java:99)
at org.rancore.testJasp.TestEsapi.main(TestEsapi.java:59)
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.owasp.esapi.util.ObjFactory.make(ObjFactory.java:86)
... 3 more
Caused by: org.owasp.esapi.errors.ConfigurationException: ESAPI.properties could not be loaded by any means. Fail.
at org.owasp.esapi.reference.DefaultSecurityConfiguration.loadConfiguration(DefaultSecurityConfiguration.java:439)
at org.owasp.esapi.reference.DefaultSecurityConfiguration.<init>(DefaultSecurityConfiguration.java:227)
at org.owasp.esapi.reference.DefaultSecurityConfiguration.getInstance(DefaultSecurityConfiguration.java:75)
... 8 more
Caused by: java.lang.IllegalArgumentException: Failed to load ESAPI.properties as a classloader resource.
at org.owasp.esapi.reference.DefaultSecurityConfiguration.loadConfigurationFromClasspath(DefaultSecurityConfiguration.java:667)
at org.owasp.esapi.reference.DefaultSecurityConfiguration.loadConfiguration(DefaultSecurityConfiguration.java:436)
... 10 more
I have tried copying the 3 ESAPI properties files in my source folder and also configuring them on build path but still I have not succeeded. I have tried many permutations and combinations to no avail.
Please guide me.
The content of property file is:
# User Messages
Error.creating.randomizer=Error creating randomizer
This.is.test.message=This {0} is {1} a test {2} message
# Validation Messages
# Log Messages

The ESAPI.properties file should have more than 3 lines in it. See for example:
https://web.archive.org/web/20150904064147/http://code.google.com:80/p/owasp-esapi-java/source/browse/trunk/configuration/esapi/ESAPI.properties
In my experience the ESAPI.properties file either needs to be in the same folder as the esapi.jar or needs to be compiled into the jar in a resources directory.
/resources/ESAPI.properties
I believe that either one should work. If ESAPI does not find the file it one location it looks in others.
The code for that is here around line 620:
https://web.archive.org/web/20161005210258/http://code.google.com/p/owasp-esapi-java/source/browse/trunk/src/main/java/org/owasp/esapi/reference/DefaultSecurityConfiguration.java

I just struggled through this one myself.
I created a folder called esapi in my C:/users/myname/ directory and loaded up the ESAPI.properties, validation.properties, and the ESAPI-AccessControlPolicy.xml which got me past all the not finding files errors. ESAPI looks in several places for the files. I'm running Windows 7 64 bit by the way.
Then I had to update some of the jars. I should have done this from the beginning, but I didn't know it. I was getting this error:
AccessController class (org.owasp.esapi.reference.DefaultAccessController) CTOR threw exception.
for every jar that needed to be a newer version, like commons collections or log4j. At the bottom of the stack trace it would reference the offending jar.
When I added the newer jars from the esapi lib directory everything just worked!
I got this message at the end in my console:
ESAPI.accessController found: org.owasp.esapi.reference.DefaultAccessController#1cb8deef
Note: There is an ESAPI_en_US.properties file, but it's the one with only a few lines in it. Just use the file in: \esapi-2.1.0-dist\src\test\resources\esapi\ESAPI.properties. That is the full complete file.

After having this problem and looking at the installation documentation (esapi-x.x.x-dist\documentation\esapi4java-core-x-x-install-guide.pdf) I found a very useful section which detailed that the properties file can be anywhere, provided a vm flag (-Dorg.owasp.esapi.resources=path") points to a particular directory.
For example, if I stick the file in a "resources" folder at the root of my project directory, then the flag would be:
-Dorg.owasp.esapi.resources="path\to\project\root\resources"

The reference SecurityConfiguration manages all the settings used by the ESAPI in a single place. In this reference implementation, resources can be put in several locations, which are searched in the following order:
1) Inside a directory set with a call to SecurityConfiguration.setResourceDirectory( "C:\temp\resources" ).
2) Inside the System.getProperty( "org.owasp.esapi.resources" ) directory. You can set this on the java command line as follows (for example):
java -Dorg.owasp.esapi.resources="C:\temp\resources"
You may have to add this to the start-up script that starts your web server. For example, for Tomcat, in the "catalina" script that starts Tomcat, you can set the JAVA_OPTS variable to the -D string above.
3) Inside the System.getProperty( "user.home" ) + "/.esapi" directory (supported for backward compatibility) or inside the System.getProperty( "user.home" ) + "/esapi" directory.
4) The first ".esapi" or "esapi" directory on the classpath. (The former for backward compatibility.)

Can you put your file (with this name) in:
D:\Eclipse-Workspace\Test\ESAPI.properties
And show us the contents and exception again.

Extract the esapi jar
create a folder named resources under org.owasp.esapi
copy ESAPI.properties to the org.owasp.esapi.resources
Build and deploy

extract the jar
add properties file under resources folder.
initially getting same error, after updating properties file it worked for me

Thanks for providing the information
-Dorg.owasp.esapi.resources="path\to\project\root\resources"
This is a good source of information and has resolved my issue

I had the same problem too. I resolved it using a little bit of James Drinkard solution. What I basically did is created a new folder with name ESAPI and added ESAPI.properties file, Validation.properties, and the ESAPI-AccessControlPolicy.xml. And archived it into a jar file and added to the lib folder under WebContet/WEB-INF and build it to the path and it worked.
*To archive it into a jar file I used windows command move ESAPI ESAPI.jar

Look at the various scripts under 'src/examples/scripts' and they will show you one easy way to control where the ESAPI.properties files is found. (This is for ESAPI 2.0 or later.)
You will find a copy of the ESAPI.properties file will be under 'configuration/esapi'.

java.lang.UnsatisfiedLinkError no *****.dll in java.library.path

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

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() {
}
}

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.

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 .

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)

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

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());

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:
Correct version of pdf lib.jar ( In my case it was wrong version jar kept in server runtime )
Make a folder and keep the pdflib jar in it and add the folder in your PATH variable
It worked with tomcat 6.

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%
Restart the IDE Idea, which appeared to work for me after I setup the env variable by adding it to the %PATH%

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")

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

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

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.

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

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.