[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: GCJ Native Proposal



Jerry Haltom wrote:
Attention Java Maintainers: This Effects You

Although I am not a DD here are my comments/questions.


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 sounds very promising to me. Especially that other free runtimes
are interested in integrating support for this binary interface.

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.

I am for (b), too.

But just for discussion - wouldn't there be a third possibility ?
(Sorry if this is a stupid question !).

What about a creating a second source package which build-depends
on the java source package to produce the native binary. This wouldn't
hit the buildds, but put the burden onto the maintainer as he has to
achieve that both source packages are in sync. The binary source package
therefore wouldn't include any source only the rules file to produce a -jbi package.

I don't know if this is reasonable / possible ?  Is there something
like source package dependencies in debian atm ?


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.

I would prefer -jbi too.

Regards,

Wolfgang



Reply to: