Sorry no one responded earlier. I'm in the process of trying to get all
of these questions/comments into the Talk page  of the guidelines
On Wed, 2008-11-19 at 00:36 -0800, Orcan Ogetbil wrote:
As I promised overholt on IRC, I wanted to share my views about the
Fedora Java packaging guidelines from a non-Java-coder point of view.
- In certain cases, we can build applications GCJ-natively
(producing .so files). But these won't work with any JVM.
The .so files will only be used by gij but the corresponding .class
files will be the same and will be used by other JVMs.
What should be the packager's primary preference? GCJ-native or
OpenJDK? The first one runs faster, but the second one has larger
Many people said they want to keep GCJ AOT bits for F11 so I guess that
will continue to be the preference.
For instance, tuxguitar (that I packaged) provides GNU Makefiles
use GCJ) for this. Are the resulting .so files going to be the same as
the ones built by aot-compile-rpm? (More about AOT later)
I don't know what tuxguitar is doing, but this small explanation from a
non-GCJ expert may help:
- gcj can compile java code in one of two ways:
1) .java source directly to C++-style .so files
2) java bytecode (.class files) to special GCJ-only .so files
- in case 2) above, the package will ship *both* the .class files
(usually in a .jar) *and* the GCJ .so files. The GCJ .so files will
*only* be read by gij -- the GCJ java bytecode interpreter -- and not by
other JVMs. Since GCJ is an ahead-of-time (AOT) compiler and has no
just-in-time (JIT) compiler like HotSpot, using these pre-compiled .so
files is faster than purely interpreting the java bytecode. The
presence of the AOT .so files (sometimes referred to as "GCJ AOT bits")
is inconsequential to JVMs other than gij/gcj.
I hope this helps. Like I said, I'm trying to capture outstanding
issues with the guidelines on the talk page in the hopes that we can
drive this to some fixes.