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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
