Question

I just tried to migrate our working Java projects from Netbeans 6.9.1 to Netbeans 7.2 and I’m experiencing a problem due to one of our project dependencies being an external JAR which uses JNI.

I created a copy of our project directory and simply opened the copies of NB projects originally created with the older version of the IDE. Everything went smooth. I can build the projects and run compiled executable JAR-s outside of Netbeans without any problems.

However when I try to debug the project, the application fails to init properly due to said dependency JAR with JNI. It’s like the JAR is failing to find a DLL associated with it (giving me java.lang.UnsatisfiedLinkError as a result). This does not happen with 6.9.1!

Why would this be happening? Do I need to explicitly set java.library.path in NB7+?

There were no changes made to the projects (not by us) and the same JDK is being used in both versions of the IDE. I suspect the newer version applies changes to the project setup silently and breaks something in the process. Anyone experienced something similar?

Edit 1:

Tried fiddling with project.properties, setting -Djava.library.path VM arg, different JDKs/JREs, … all to no avail. This is driving me nuts. Obviously I’m doing something wrong.

Answer 1

I figured out what went wrong. This only became apparent after I got source of the external JAR (ext.jar from now on) in form of a Netbeans project so I could debug it.

ext.jar may load one of several DLLs depending on certain conditions. It constructs a file path to the appropriate DLL by using SomeClass.class.getProtectionDomain().getCodeSource().getLocation().getFile() and then calls System.load(path) with it’s value. This path is different between the two versions of Netbeans. ext.jar is actually being used by another JAR (which is also a Netbeans project), which in turn is used by the main executable JAR of the application (also a project).

Main JAR (Netbeans project)
 ˪ Common JAR (Netbeans project)
     ˪ External JAR with JNI (ext.jar)

All external libraries in our project setup are placed within a directory at the same level where all the projects reside. This enables multiple projects to use a common set of libraries. Projects use relative paths to reference the libs.

CommonLibraries
MainJARProjdir
CommonJARProjdir
RandomProjdir1
…
RandomProjdirN

When Main is built, Common must be built before it (Common is a project dependecy of Main). In the process of building Common (by default) all dependency JARs get copied to ${common.proj.dir}/dist/lib. The copy process is of course unaware of the fact that it should copy DLLs along with ext.jar.

The root of the problem is however different handling of dependencies in 6.9.1 and 7+. If I specify ext.jar to be a dependency to both Main and Common (which is what was done, even though Main doesn’t directly use any code from it) 6.9.1 will use the ../CommonLibraries/ext.jar when debugging, which always has all the required DLLs beside it, while 7+ will always use ${common.proj.dir}/dist/lib/ext.jar, which is missing the DLLs.

After recognizing what the problem is, the solution becomes trivial. I added a -post-clean target to build.xml of Common, which simply copies required DLLs from ../CommonLibraries/ to ${common.proj.dir}/dist/lib/ after each clean. It worked. This should be done either way – for completeness sake.

The reason for different handling of dependencies in the two versions of the IDE appears to be a new checkbox which is present in Project Properties/Build/Packaging called Copy Dependent Libraries. Ticking that off for Common also works. Note that this checkbox is enabled by default (even for library projects).