In my new and continuing series on hair-pulling, teeth-gnashing Java error messages, I am proud to present:

java.lang.UnsatisfiedLinkError: no j3dcore-ogl in java.library.path

Just for fun, I’ve been working through Pro Java 6 3D Game Development: Java 3D, JOGL, JInput and JOAL APIs . I have been trying to rework the example code and make it my own as I go through the chapters.

Anyway, I built a small “Hello 3d” app but when I attempted to run it I get the above UnsatisfiedLinkError. What was odd was that the sample code from the book ran without any problems, but I was getting this error.

For some Java libraries, there are native code (C++ extensions, basically) that Java needs to work with that particular feature. Java3d is a prime example. You need to put the j3dcode.jar, j3dutils.jar, and vecmath.jar files on your CLASSPATH. Additionally, you need to put the native code, j3dcore-ogl.dll (j3dcore-ogl.so on Linux) onto the PATH. This can be in the JRE/bin folder, but the Java3d isntall file says to avoid sticking it in there, as it can cause problems. I choose to keep all my Java files in my D:\java\lib folder. — in this case the java3d-ogl.dll is in D:\java\lib\j3d\bin. And since I am using Eclipse, I configure Eclipse with a user library like this:

Eclipse dialog for User Libraries in the Java Build Path

I focused on the “java.library.path” part of the error message. I configured Eclipse correctly above, and had my app spit out the System.getProperty (“java.library.path”) to the Console. It was correct.

But it didn’t work! At. All. Mysteriously, the sample code–which was configured to use that same Eclipse User Library, worked just fine.

After a lot of Googling and talking to myself (grr, I’ll show you unsatisfied…). I noted in my TaskBar that the icons for the sample Application (Life3d) and my little app where different. And a lightbulb went on. Sample code was running Java 1.6, and mine was running under Java 1.5. (I had chosen JDK 5 because I was thinking about redistribution to some non-geek friends, and figured more people would have Java 1.5 than 1.6.)

Now–in theory, there should be no difference. Not sure if this is a feature or a bug–the Eclipse stack is sometimes too big to tell. But my Eclipse is running on Java 1.6 (Vista x64), and perhaps the way it is creating the class loader for the 1.5 JVM it is not picking up that .dll, even though the .dll was on my PATH (or in my Eclipse native library location).

My fix: Inside Eclipse 3.4, swapping my project to use Java 1.6 as my JVM fixed the problem. Hurray! I have yet to test building a JAR and trying it outside of Eclipse… I’m just trying to get through a few more chapters so I can get to the fun stuff.

Hope this helps someone.