JNI: UnsatisfiedLinkError

S

SPG

Hi,

I have a java applet that makes calles via JNI to a C++ DLL.
This aplet is signed for both SUN and MS JVMs.

The DLL is packed inside the JAR file and downloaded onto the user's
harddrive into the user.home directory, then loaded.

Using the SUN JVMs, this works fine. The user has to accept the certifiacte,
then the user.home dir is located, we extyract the DLL from the jar and then
call loadLibrary(). Works a treat.

The exact same set of code does the following:

1. ClassA.class.getResource("/" + dll); returns a path to
c:\windows\java\trustlib for the dll resource path, not the cab file it is
stored in (SUN JVM returns the url to the entry in the jar)

2. I manually copy the dll to user.home (MS Version says this is
"C:\windows\java"). A call to System.loadLibrary("MyDLL") throws an
unsatisfied link error saying the dll is not on the shared path.

I have googled a lot on this and found only similar questions to this, but
no answers.

Has anyone got a clue where what and why?

Steve
 
G

Gordon Beaton

The exact same set of code does the following:

1. ClassA.class.getResource("/" + dll); returns a path to
c:\windows\java\trustlib for the dll resource path, not the cab file it is
stored in (SUN JVM returns the url to the entry in the jar)

2. I manually copy the dll to user.home (MS Version says this is
"C:\windows\java"). A call to System.loadLibrary("MyDLL") throws an
unsatisfied link error saying the dll is not on the shared path.

AFAIK, the dll must be in your PATH on windows.

Another solution is to use System.load(), which lets you specify a
full path to the file.

/gordon
 
S

SPG

Gordon Beaton said:
AFAIK, the dll must be in your PATH on windows.

Another solution is to use System.load(), which lets you specify a
full path to the file.

/gordon

Hmm.. This is exactly what is happening.
The user.home path property is pointing to an area on my PATH env var.
The SUN version works fine, but the MS version will not load the dll no
matter where I put it

Steve
 
R

Roedy Green

The exact same set of code does the following:

1. ClassA.class.getResource("/" + dll); returns a path to
c:\windows\java\trustlib for the dll resource path, not the cab file it is
stored in (SUN JVM returns the url to the entry in the jar)

2. I manually copy the dll to user.home (MS Version says this is
"C:\windows\java"). A call to System.loadLibrary("MyDLL") throws an
unsatisfied link error saying the dll is not on the shared path.

I have googled a lot on this and found only similar questions to this, but
no answers.

See http://mindprod.com/jni.html

the easiest way to handle this is with JAWS. It then puts the DLLS in
an appropriate place for you, and selects the platform specific one
automatically.

I gave up on dynamic copying back in the Netscape days.. The problem
was it did not seem to notice new dlls. Only when the JVM restarted
did it see the newly appeared dlls.
 
R

Roedy Green

AFAIK, the dll must be in your PATH on windows.

Specifically on the system property java.library.path which will
contain the system path plus some extras.
 
R

Roedy Green

Another solution is to use System.load(), which lets you specify a
full path to the file.

the catch there is your java code then becomes platform specific.
loadLibrary lets you use a generic name that is converted to the
platform name e.g. libxxxx.so or xxxx.dll
 
R

Roedy Green

The SUN version works fine, but the MS version will not load the dll no
matter where I put it

you don't precede the name with "lib" in Windows as you do in Solaris.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top