gcj4 changes : Please Comment

[Michael Koch]

On Sun, Feb 13, 2005 at 12:28:00PM -0600, Jerry Haltom wrote:
> 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. =)

Also note the disadvantage: on smaller systems with less memory and/or
slower cpu this can take a very long time and probably fail due to less
memory. It should be at least configurable by the admin adn disabled by
default.


Michael