JNI library path

[Tom]

i have create a dll (my.dll) for my java program to call the functions
in my.dll

It requires external dlls, b.dll, c.dl to do further processingl...

right now i am able to run my java program calling the function in
my.dll

however i need to put b.dll, c.dll into c:\windows\system32

i need to put all the dlls into one specific folder for easy
usage..instead of having b.dll, c.dll in c:\windows\system32, put all
dlls into c:\all-dll

how can i achieve this?

my.dll is called with this method
System.load("C:\\all-dll\my.dll");

 

[Jean-Francois Briere]

It,s better to do:

System.loadLibrary("my"); // no absolute path and no (OS-specific)
extension

And then do on execution:

java -Djava.library.path=C:\all-dll YourClass

Regards

 

[Tom]

It,s better to do:

System.loadLibrary("my"); // no absolute path and no (OS-specific)
extension

And then do on execution:

java -Djava.library.path=C:\all-dll YourClass

Regards

is it possible to change the library path during runtime?
as such, i would read the library path from a config file and set the
library path in the program during runtime..

 

[Chris Uppal]

System.loadLibrary("my"); // no absolute path and no (OS-specific)
extension
Agreed.


And then do on execution:

java -Djava.library.path=C:\all-dll YourClass

Does that cause Windows to resolve a.dll and b.dll when they are loaded from
my.dll ? I'm willing to believe it is (presumably the JVM must add
java.library.path to the Windows %Path%), but would be surprised even so.
(Unfortunately, it's too much effort to set up a test.)

What I would do is ensure that my.dll, a.dll, and b.dll were all on the
%Path% -- either by changing the %Path% or by finding somewhere suitable on the
%Path% for them to live. In normal applications, the best place is in the same
directory as the application, but that might be awkward for Java (depending on
how the OP's deploying the program).

Another factor to consider is how my.dll is loading a.dll and b.dll. If it is
loading them implicitly (say by using a .lib stub) then the OS and/or the stub
will look for the secondary DLLs. But it's also possible that my.dll is
loading a.dll and b.dll from an explicitly defined location, in which case all
bets are off.

-- chris