gcj4 changes : Please Comment

[Arnaud Vandyck]

I like the idea of having native java package and your proposal sounds
good. We have to discuss this.

One thing I don't like is to change the name of our jars in
/usr/share/java. Having the so files reflect the jar file could be good
but I don't know if gcj4 will like this idea ;-)

The mapping file could solve the whole thing, we have to think about it.

The /usr/lib/java is a good place to put all these arch-dependant libs
but if we add a new directory, shouldn't we ask LSB or another standard
assoiation or so?

Jerry, sorry for the very late reply and many thanks for your work and
your proposal.

Sun, 13 Feb 2005 12:28:00 -0600, 
Jerry Haltom <wasabi@larvalstage.net> 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. =)
>
> ----
> Jerry Haltom <wasabi@larvalstage.net>
>
>
> _______________________________________________
> pkg-java-maintainers mailing list
> pkg-java-maintainers@lists.alioth.debian.org
> http://lists.alioth.debian.org/mailman/listinfo/pkg-java-maintainers
>

-- 
  .''`. 
 : :' :rnaud
 `. `'  
   `-    
Java Trap: http://www.gnu.org/philosophy/java-trap.html