JNI: UnsatisfiedLinkError

[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

 

[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

 

[SPG]

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

 

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

 

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

 

[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

 

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