Thread: [java-gnome-hackers] Libraries vs Packaging (1): Linkage

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Something I have been musing about for a while is how we could implement
optional dependencies into java-gnome.

Right now you put gtk-4.0.jar on your classpath, and you're done. That's
a Good Thing™

That .jar magically loads libgtkjni-4.0.20-dev.so [the name does not
matter] which is linked against ... everything. :(

The big case that pushes this is WebKit. We'd like to include coverage
of WebKitGtk soon. But either you have it on your distro and can easily
build against it, or you don't, and it becomes a blocker against you're
being able to build java-gnome from source.

Another example is GtkSpell; at the moment I don't use it, and so seeing
it in the output of ldd tmp/libgtkjni-4.0.20-dev.so is a bit of a
surprise

Because Java only loads classes when required, it doesn't cost
developers anything to have a single .jar to include in their classpath,
and indeed that is MUCH better than having to include 14 .jar files in
some complex stack of dependencies that no one cares about.

The libraries, on the other hand, bother me a bit.

I've been wondering if we should have

tmp/libglibjni-4.0.20-dev.so
tmp/libgtkjni-4.0.20-dev.so
tmp/libgnomejni-4.0.20-dev.so
tmp/libwebkitjni-4.0.20-dev.so

etc that would be loaded by System.load() calls in the individual
package Plumbing classes.

The usual wisdom is that more shared libraries are bad. If that is true,
then our single .so is a good thing. On the other hand, if tighter
linkage in many .sos would perhaps reduce our virtual memory demand? Our
footprint appears huge in top(1), gnome-system-properties etc and while
I know those are not much of a measurement tool, I am conscious that
over time memory pressure adds up and I'd like to make sure we're doing
the right thing.

AfC
Phuket