Develop Reference

AIX: "java.lang.UnsatisfiedLinkError" but the library exists

I'm using JNI to call a shared library named "libmy_jni.so" from my java code. Those are working good without any problem in other OS's but in AIX, I see the following error. I've checked that the LIBPATH and LD_LIBRARY_PATH(in case) are set correctly and matched x86 module with 32bit java(and x64 with 64bit java).
Exception in thread "Thread-1" java.lang.UnsatisfiedLinkError: my_jni (No such file or directory)
The java code loading the library is,
File sofile = new File("libmy_jni.so");
if(!sofile.exists())
{
System.out.println("can't find the moudle.");
System.exit(1);
}
System.loadLibrary("my_jni");
As I know, the most cases causing the error above are incorrect library path or unmatched 32/64bit architecture. But in my case I don't see what could be the reason.
>>file libmy_jni.so
libmy_jni.so: 64-bit XCOFF executable or object module not stripped

Java extensions loader cannot find extensions after Java auto updates when application is running

Java uses "java.ext.dirs" property to get the directory from which extensions should be loaded. My application starts (through JNI), runs OK and then (after java's auto-update) I get:
java.lang.InternalError: java.io.FileNotFoundException: \C:\Program Files\Java\jre1.8.0_60\lib\ext\dnsns.jar
The updated version is in jre1.8.0_65, so no wonder the extension cannot be found. Any idea how to fix this?

Sqlite java.lang.UnsatisfiedLinkError in linux

I have a program that uses Sqlite database. It works fine on Windows (exported jar or directly in Eclipse) but when I move it to linux server (plan is to use run it at certain intervals, cron job). I'm exporting it to jar from Eclipse and packing the sqlite-jdbc4-3.8.2-SNAPSHOT.jar with it. Error is this:
/$ /usr/bin/java -jar /home/username/Software.jar /home/username/
java.lang.UnsatisfiedLinkError: /tmp/sqlite-3.8.2-amd64-libsqlitejdbc.so: /tmp/sqlite-3.8.2-amd64-libsqlitejdbc.so: failed to map segment from shared object: Operation not permitted
Exception in thread "main" java.lang.UnsatisfiedLinkError: org.sqlite.core.NativeDB._open(Ljava/lang/String;I)V
at org.sqlite.core.NativeDB._open(Native Method)
at org.sqlite.core.DB.open(DB.java:161)
at org.sqlite.core.CoreConnection.open(CoreConnection.java:145)
at org.sqlite.core.CoreConnection.<init>(CoreConnection.java:66)
at org.sqlite.jdbc3.JDBC3Connection.<init>(JDBC3Connection.java:21)
at org.sqlite.jdbc4.JDBC4Connection.<init>(JDBC4Connection.java:23)
at org.sqlite.SQLiteConnection.<init>(SQLiteConnection.java:44)
at org.sqlite.JDBC.createConnection(JDBC.java:113)
at org.sqlite.JDBC.connect(JDBC.java:87)
at java.sql.DriverManager.getConnection(DriverManager.java:582)
at java.sql.DriverManager.getConnection(DriverManager.java:207)
....
So before you ask, I've made sure that sqlite-3.8.2-amd64-libsqlitejdbc.so in /tmp/ has all permissions (rwxrwxrwx). Still that native library is causing problems. It does get copied in /tmp/ folder though. That being said I totally suck in Linux... and for that reason I'm pretty much clueless what to try next.
What should I do? Switch connector?
EDIT:
Solved the problem by using System.setProperty("java.io.tmpdir", "/home/username/"); Apparently it for some reason couldn't execute the native library from tmp folder... Probably because it was created by root. Also I had to revert back to sqlite-jdbc-3.7.2.jar because the new one crashes on linux.

I had same problem, and I found the solution in this GitHub issue:
JAVA_OPTS=-Djava.io.tmpdir=/path/to/some/other/tmpdir bin/cerebro
Also look at this other SO answer.

RMI Registry Issue: rmiregistry may cause unintended exceptions when binding with codebase using the "file:" URL scheme

Please see the passage "RMI Registry Issue" of this article for the background on Java Update 1.6.0_29 first.
If I understand correctly (I'm german), the update introduces a bug in the rmiregistry which fails to work with the file: pattern in the codebase.
I.E. the following won't work any more with 1.6.0_29:
-Djava.rmi.server.codebase="file:myproject/bin/ ..."
We are currently using the feature of having a codebase with file: syntax. Does anyone know a workaround for making this work?
Note: No, we do not want to start a local webserver or ftp server.
Update:
On Naming.bind this exception is thrown:
java.rmi.ServerException: RemoteException occurred in server thread; nested exception is:
java.rmi.UnmarshalException: error unmarshalling arguments; nested exception is:
java.lang.ClassNotFoundException: access to class loader denied
at sun.rmi.server.UnicastServerRef.oldDispatch(UnicastServerRef.java:400)
at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:248)
at sun.rmi.transport.Transport$1.run(Transport.java:159)
at java.security.AccessController.doPrivileged(Native Method)

I had the same problem, and can confirm that downgrading JDK to earlier version solves the problem. I know, it's not a solution you're looking for, but at least it makes it to work.

Take running in windows as an example:
Step 1. In C:\Users\Jimmy.java.policy (create it if not exist), append below content:
grant { permission java.security.AllPermission; };
Of course "C:\Users\Jimmy\" is the user home, please change to your home accordingly.
Adding AllPermission is just for quick resolving your issue. you'd better config a more accurate FilePermission here.
Step 2. Start rmiregistry:
C:\JDK\bin>rmiregistry -J-Djava.rmi.server.codebase=file://C:/workspaces/MyLab/target/classes/
(Please note codebase must ended with "/")
Step 3. Run your server and client program.
References:
http://docs.oracle.com/javase/7/docs/technotes/guides/rmi/codebase.html
http://docs.oracle.com/javase/7/docs/technotes/guides/security/spec/security-spec.doc3.html
http://docs.oracle.com/javase/7/docs/technotes/guides/rmi/enhancements-7.html

It looks like there is no workaround because it is a bug, so wait for the fix
See details at
https://bugzilla.redhat.com/show_bug.cgi?id=751203
Code fix
http://icedtea.classpath.org/hg/icedtea6/rev/67df573b0734

If you do not need dynamic code downloading (in which case you can use ftp codebase) the solution is simply to set CLASSPATH environment variable to the path to your jar file:
Windows:
set CLASSPATH="path_to_jarfile"
Linux (batch):
CLASSPATH="path_to_jarfile"
export CLASSPATH
Best place to do it is in some script that invokes the RMI server.
Setting class path in the command line (-cp option) when starting RMI server does not help because it does not affect rmiregistry classpath!

If you start the rmiregistry in the working directory of your project, it works.
So essentially working directory of your project and current directory for rmiregistry should be same.

I recently encountered this issue as well. I can confirm that when using the file: protocol the rmiregistry must either:
be started in the root of the directory containing the shared classes; or
set the classpath to point to the shared classes or shared class jar; or
use a protocol other than file:// (I set up ngnix and served the jar from that).

Maybe not what you want, but you could resolve this with classpath rather than codebase. The client JVM will work fine if you add the required classes to its classpath. If you are using the file: URL scheme, then the classes must already be available on the localhost.

I had the same problem but I couldn't change the JDK version. Turns out you can solve it by running/starting the rmiregistry from the same directory as your code base, which in my case was target/classes. So cd project/target/classes and then run rmiregistry &

Java Attach API: changing java.library.path dynamically

When using the com.sun.tools.attach API on my Windows machine, I get the following error when making a call to
VirtualMachine.list()
java.lang.UnsatisfiedLinkError: no attach in java.library.path
The reason is the missing attach.dll. The attach.dll is located in $JRE/bin/. When starting my Java program with -Djava.library.path=[Directory to the attach.dll] everything works out without error output.
Now, I don't want to add every Java program start this ugly JVM parameter. Therefore my questions are:
Is my machine not configured right and the $JRE/bin/ should be in the library path anyway?
If not, how can I add the path dynamically? System.setProperties("java.library.path",StringOfThePathToTheAttach.dll); does not work out. The library path is changed, but the error apperas anyway. Has this something to do with SecurityManager or JVM start up?

Just found a link that might answer your question
"The java.library.path is read only once when the JVM starts up. If you change this property using System.setProperty, it won't make any difference."
http://fahdshariff.blogspot.jp/2011/08/changing-java-library-path-at-runtime.html

Your System.setProperty("java.library.path", StringOfThePathToTheAttach.dll); should work. My guess is that you're calling it too late. In other words, there is an attempt to access the DLL prior to you setting the property.
Can you output the current value for java.library.path after the property is set in code and again before the offending method call?
i.e. If you see "Before attach.dll call" output prior to seeing "After setting property", you know where your problem is.
Edit:
A better way to point to native libraries is to use System.load(StringOfThePathToTheAttach.dll) - again, before the offending line of code.

System.setProperty("java.library.path", System.getProperty("java.library.path") + File.pathSeparator + FOLDER_THAT_CONTAINS_ATTACH_DLL);