Odejava installation requirements?

Game Mechanics
#1

I’m having some issues with the ODEjava being deployed on a client’s machine and have been trying to define a definitive list of installation requirements. Naturally, a developer’s machine like mine has a lot of cruft on it, so knowing what libraries and dependencies exist is somewhat problematic. It’s the typical “well it works here, no idea why it doesn’t work there” issue.

One of the more problematic issues is the UnsatisfiedLinkError being generated. The interesting bit is that it is actually loading the DLL up, but when you make any call to one of the native methods, then it generates the exception. That is, System.loadLibrary() works correctly, but making a method call on any of the org.odejava.ode.Ode methods causes the ULE.

When I have encountered this form of problem before, it’s been because of a compilation incompatibility of the native code with the JDK version that the java-side library was built with. The client’s machine is JDK 1.4.2_05, and I’m running with the pre-built win32 release library. I’m wondering what JDK version the current pre-built library was generated and compiled with. Running strings over the .dll is finding the method names in there, so it’s some sort of JVM name mapping issue.

Also, is there any chance of removing all the Apache project dependencies from the library? So far, to get the code to run, I’ve had to install about 4 megs of third-party libraries, which is really annoying as eventually this is going to be heavily distributed over the net (one of the integration paths I’m working on is adding it to Xj3D, and all the extra installation issues from the apache dependencies are a major pain to deal with).

#2

4meg of apache dependancies? log4j is only 352k and ant is purely optional (and only if you are building). We could abstract the logging a bit so a light weight logging .jar could be substituded in at deploy time (I wouldn’t be surprised if someone has already created a light weight version of log4j with the same method signatures already which would save us the effort, I am only speculating though).

Dealing with native libraries is a pain.

For deploying:

  1. (prefrably) deploy with java web start, this removes most of the pain
  2. at runtime (i.e. in your shell scripts) specify the java.library.path (-Djava.library.path) to point to your .dll directory

For developing (probably not recommended for deploying as you may run into version problems if your user upgrades although it would technically work).

  1. copy the .dll’s to the current java.library.path (query the System class to find this out. The Xith3D install guide has some good info on doing this. It’s basically the same as odejava - just different .jar files.

Regarding Xj3D - will you be writing a custom display package for Odejava? It currently supports Xith3D and Java3d. It’s quite simple to add new display packages and there are already some docs on doing this. I’m happy to answer any questions you may have.

Will.

#3

The bit that you’ve missed in my original email is that the application is loading the DLL, it just is having problems mapping the API calls for some reason. Typically this is a compilation dependency problem. Did you compile either the Java or the native code using an early version of JDK 1.5, for example.

As for the library path, there is no need for that. It’s already sitting in the jre/bin directory and everything else sitting in there is working fine. We do a bulk install that puts Jinput, JOAL, JOGL, ODE, some of our custom input device code and about half a dozen other libraries in those two dirs (native and JARs). Everything is working fine except for ODE :-[

As for the extra libraries needed - it’s also needing the entire Xerces distribution as well as something else that is pulled in through 3rd-party dependencies. Don’t remember it offhand, I still haven’t woken up enough yet …

#4

Baaah. All sorted out now. Wonders what a coffee and a large dose of cold medicines will do.

A number of our libraries are sitting in the lib/ext directory, meaning that they operate within the same permissions structure as all the other libraries in there. Our code had been calling System.loadlibrary() directly on the ODE stuff and then directly interacting with the raw ODE calls. However, on the client’s machine our code was no longer in the lib/ext meaning that the loadLibrary() call would succeed, but the permissions were not allowing it to do anything. In order for it to work, we had to make a call to the ODE library OdeJava.init() so that the library loading was performed by code with the same permissions/classloader setup. Now everything works as advertised.

#5

I’m still using JDK 1.4.2 for now (waiting for 1.5 on Macs before I upgrade).

As for Xerces, I forgot about that. This is only needed for the org.odejava.xode package and that is a purely optional package. XODE is an XML based ODE file format that I created with a lot of feedback from the ODE community.

If you want that XODE parser, then Xerces you must have. To free yourself from that dependancy (if you don’t need that parser), simply delete that package. Personally all of my complex ODE structures are stored in XODE XML files, I find it far easier to create and maintain them this way as opposed to defining them in code.

Will.