views:

109

answers:

4

I made a simple java program that sends bytes to the parallel port, which uses a .dll along with two other classes (pPort.java and ioPort.java) to accomplish it, and it works perfectly fine.

However, I started making another program on NetBeans IDE which has a similar function. It compiles perfectly, but when I run it I get:

Exception in thread "AWT-EventQueue-0" java.lang.UnsatisfiedLinkError: parallelporttimer.ioPort.Out32(SS)V

From what I understand, it's failing to call the .dll file I put on System32. But I don't understand why, since the other program, which is basically the same but made manually without any IDE, runs fine. Do I have to specify something in NetBeans for this to work? Any help with this would be greatly appreciated.

+1  A: 

Have you looked into the two classpaths for both programs (standalone and IDE) ?

JRL
+3  A: 

DLL needs to be in the path or current working directory in order to be loaded.

I'm guessing when you've ran your program without IDE the latter was the case. When you run it from within NetBeans "working" directory is likely netbeans/bin folder, so DLL can't be found. Add its location to path and you should be good to go.

ChssPly76
+2  A: 

I don't do Netbeans, but it sounds like that Netbeans maintains its own java.library.path. Best what you could try is to specify it yourself as VM argument:

-Djava.library.path="c:/path/to/dll/files"
BalusC
+1  A: 

An UnsatisfiedLinkError message typically indicates that the library path is set but does not include the library that you are trying to load. On Windows platforms, you should extend the PATH using

PATH = %PATH%;C:\path_to_dll_file

On UNIX platforms, you should extend the library path using

setenv LD_LIBRARY_PATH mylibrarypath

However, as far as I can remember (I'm not under Windows), System32 is in the PATH so I suspect NetBeans to overwrite it by settings its own PATH.

To solve this on NetBeans, you might want to check http://wiki.netbeans.org/DevFaqNativeLibraries which is mentioned in this message from Wade Chandler, a NetBeans Dream Team Member ;-)

PS: You can also use the java.library.path system property but keep in mind that this system property only works to resolve the immediate native library that you are loading in your code. Loading of other dependent libraries is left to the first library. The JNI library that you load will rely on the OS dependent way to resolve its references (this applies to the solution of the FAQ too IMO so I'm still not 100% convinced its a good solution).

Pascal Thivent