On Dec 29, Chris Toshok wrote:
> "Aaron M. Renn" wrote:
>
> > Brian Jones ([EMAIL PROTECTED]) wrote:
> > > I may have changed a couple of lib names today without changing the
> > > load in the .java file to match. My mistake. I'll fix it tomorrow.
> >
> > Our Java files should be loading names like "javanet". Now this maps
> > to a native library name. In Japhar, supposedly either libjavanet.so
> > or libjaphar_javanet.so work, but I've only ever gotten the latter to
> > do so. I wonder if we are hardcoding a library name someplace in our
> > native code.
>
> oh, you know what this might be? Jochen fixed a bug in MapDLLName (or
> whatever that method is) that gives you the name of the .so to load. that
> can only return one name, and it returns libjaphar_%s.so. hmm.. i'll take
> a look at this tomorrow.
This was necessary for the jdk1.2 classloader which checks if a
library exists (via File.exists) before even calling the native method
to load the lib. So for jdk1.2 MapDLLName must even return an
existing file name. This problem is because most of the loading
process is done in java in jdk1.2, so japhar cannot manipulate it.
The 1.2 API, where the classloader (which could be a custom class
loader) finds a library and not java.lang.Runtime, makes it really
hard to stay with the current multiple name scheme
(lib{japhar_,}%s.*). I would propose the following algorithm:
System.mapLibraryName returns "lib%s.so", to load custom JNI libs via
custom ClassLoaders just the same way it does under sun's jdk.
The bootstrap's ClassLoader.findLibrary should then first try to
locate libjaphar_%s.*, and if it doesn't succeed lib%s.*. Sadly, that
means that japhar doesn't work with the jdk-1.2 java.lang.ClassLoader.
Jochen
