[java-gnome-hackers] Embedding the library path

[Andrew C. <an...@op...>]

        [We do 'way too much on IRC, and I realized this list is looking
        a little dead. That's a shame. We'll try and correct that]

One of the constant pain points of using java-gnome is having to specify
-Djava.library.path=whatever to the VM every time you attempt to run
something.

While the problem goes away if using a copy of java-gnome installed to
the system prefix (ie, /usr) via a distro package, there is the
attendant problem that if you have java-gnome installed and meanwhile
try to run something in a checkout and forget the to do
-Djava.library.path=tmp or whatever you'll end up picking up the wrong
native code [we now catch that problem, but still]. And worst of all,
even if installed, if you're on Gentoo the gentoo-java team installs its
native components to a non standard location
(/usr/share/java-gnome-4.0/lib in our case) meaning that you've still
got to define java.library.path. What a pain in the ass.

I was talking about this with Kenneth Prugh the other day, and we
realized that in a Linux environment the target libdir location is a
*known* commodity. We know, as of configure time, exactly where to find
the library. So why not just look there?

I spent a while trying to fudge this location into java.library.path at
runtime, but that's not possible - in the Open Java implementation
anyway, the value of java.library.path is cached really early on, before
user code can get to it. So changing that property doesn't have any
effect.

But it turns out there is an alternate way to load native libraries from
Java code, and that's System.load(). Unlike System.loadLibrary() [which
searches (only) java.library.path for the .so you're attempting to load]
you specify the exact absolute path of the file you want to load. Well,
shit, we have that. So, yeay!

I've done essentially this on a branch. See
bzr://research.operationaldynamics.com/bzr/java-gnome/hackers/andrew/native-library-loading/ 

Having it load the library as it will be installed was easy. The tricky
part was arranging things so that if you're using java-gnome in-place as
built (but not yet installed) that it would still work. This is very
important for people who are simultaneously hacking an app and hacking
on java-gnome at the same time. That fall back case involves some fairly
voodoo code (you have to find out the URL of the code (ie gtk-4.0.jar)
came from. Not easy).

I'm happy we've covered off all the corner cases, but testing by you
would be appreciated before I merge it to 'mainline'.

This is actually a pretty momentous improvement, and assuming it holds
up, I'd like to do a release with it ASAP.

AfC
Sydney

-- 
Andrew Frederick Cowie

Operational Dynamics is an operations and engineering consultancy
focusing on IT strategy, organizational architecture, systems
review, and effective procedures for change management. We actively
carry out research and development in these areas on behalf of our
clients, and enable successful use of open source in their mission
critical enterprises, worldwide.

http://www.operationaldynamics.com/

Sydney   New York   Toronto   London