GCJ Native Proposal
Attention Java Maintainers: This Effects You
This is a recap of an ad-hoc discussion a number of Java maintainers had
a few minutes ago in #debian-java concerning our direction with regards
to including native GCJ compiled Jar files in our packages.
Brief overview: gcj-4.0 is now in experimental. What it gives us is the
ability to package native binary .so files along side their .jar
counterparts for usage with gij (the GCJ interpreter, a virtual
machine). When these .so files are present (in the correct location,
registered with the correct mechanism) gij will load them automatically
and use them in the place of the corresponding .jar file. The main
motivation for this is speed. There is no JIT overhead involved and it
runs native, not interpreted. It is worth noting that the Kaffe folks
want to integrate support for this binary interface into Kaffe.
This begs the question then: How do we make these native .so files
available in our packages to our users. A number of ideas were
considered:
a) Include the .so along with the .jar in the same deb.
b) Create a separate package for the .so.
The first one (a) can be discounted because it would convert every Java
package into a binary: arch package. This isn't feasible for obvious
reasons: we like archive space!
The second one is the best one. It minimizes archive space. It will hit
the buildds however, as it requires the binary-indep build process in
order to run binary-arch.
The -java package would ideally Recommend the second package.
I would like to name the secondary native packages with a -jbi prefix
(Java Binary Interface). Some people like the name -bcabi because that
is what the GCJ folks tend to refer to it as. BC ABI: Binary Compatible
Application Binary Interface. I don't think bcabi is descriptive at all.
Of course, all of this requires buy-in from every Debian Java
maintainer. Please respond with questions and/or comments!
--
Jerry Haltom <wasabi@larvalstage.net>
Reply to: