gcj4 changes : Please Comment

[Jerry Haltom]

Some of you may have noticed that gcj4 is in experimental. Because of
this I would like to start talking about some changes to java-common to
take advantage of the native Java features that gcj4 offers us.

gcj allows .jar files to be translated into .so files. These .so files
can be looked up at runtime by the gcj classloader. This means that when
the VM attempts to load the class org.foo.bar, it can actually resolve
this class to /usr/lib/java/bar.jar.so or something similar by using a
mapping database of class hashes to .so locations.

To take advantage of these features, we need to come to agreement on
what to name our .so files, where to put them, and how to generate this
database.

A logical choice would be to generate a .jar.so file in /usr/lib/java in
the exact manner that is it created in /usr/share/java. Same name, .so
appended. Same symlinks from unversioned name to versioned name.

In addition to this, a database of class->.so mappings needs to be
generated and kept up to date. This generation is handled by
"gcj-dbtool-4.0". The most obvious way is to regenerate this database in
the postinst scripts of packages which contain native .so files. At
present it doesn't look like there is a good way to incrementally create
this file as each package is installed, so complete regeneration might
be required on every package install. I had heard that upstream was
working on this. We would likely introduce an 'update-java-native'
script or something for this purpose.

We need to decide how we want to name these native packages. Should we
just append -native to the end of our -java packages producing
libname-native. That's sort of how some packages are referring to jni
bindings currently.

It is worth noting that this makes arch-dependent routines in a packages
rules file dependent at build-time upon their arch-independent
counterparts. This would cause more stress on the buildds.

Because I happen to like the ideas above, I am going to start hacking on
the related packages, java-common, mostly, to set this up. Nothing I do
is final, it is simply to satisfy my need to experiment. =)

----
Jerry Haltom <wasabi@larvalstage.net>