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