[Bug 168012] Review Request: kawa

[bugzilla at redhat.com]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug report.

Summary: Review Request: kawa


https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=168012





------- Additional Comments From green at redhat.com  2005-09-11 13:56 EST -------
(In reply to comment #7)
> I am quite experienced with traditional java, but the fedora java setup
> leaves me a little stunned :-(

Hopefully you'll recognize its genius once you get use to it :-)

> Ok, what I found out is that you don't compile with gcj, but use a "simulated"
> traditional jdk setup, i.e. compile java byte code with ecj and interpret it
> with gij. Is this correct? 

Yes, this is close.  The simulation is provided by java-gcj-compat, whose goal
is to let us build and run random java projects unmodified on our Free Software
stack.

> Then you take the additional step to gcj-compile
> the whole .jar and put it in the gcj database.

Yes.  If you run "gcj-dbtool -l /usr/lib/gcj-4.0.1/classmap.db" you'll see a lot
of lines like:

[1153] c6514c3f8fa5e678faa7555b1fd449 -> /usr/lib/gcj/jython/jython-2.2.jar.so

When the gcj runtime loads bytecode for a class, it computes a cryptographic
signature of that bytecode and looks it up in this database.  In the case above,
when libgcj loads the bytecode corresponding to c6514c3f8fa5e678faa7555b1fd449,
it should look for a natively compiled version of that class
/usr/lib/gcj/jython/jython-2.2.jar.so instead of interpreting the bytecode.

> The other way is to compile the .java files individually and link to a native
> binary (this is what --with-gcj) does.
> Are both ways equivalent in that a native version is executed, in the one
> case an executable in the other case a shared library? Can one prefer
> one over the other?

We prefer the method I described above.  There are lots of reasons to like it:

- It makes building and running java projects much simpler.  Instead of
maintaining wildly patched and unique build systems for these projects, we can
use the upstream build system virtually unchanged (see
http://sources.redhat.com/rhug for more insight).  (btw, kawa is one of the rare
projects that had special gcj build infrastructure)

- Many projects are written to load, link and run bytecode through special
ClassLoaders.  The classmap mechanism lets us still load and run native versions
of these classes.  This was impossible before.

- Java also lets you load, link and run classes by name
(Class.forName("MyClass")).  We had a very fragile system for handling this
before (see Fedora Core 1).  The new mechanism has proven to be extremely robust.



-- 
Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.