Re: Reconsidering gcjx

[Andrew Haley <aph at redhat dot com>]

Tom Tromey writes:

 > Historically we've wanted to have a 'native' java-source-code-reading
 > compiler, that is, one which parses java sources and converts them
 > directly to trees.  From what I can remember this was based on 3
 > things:
 > 
 > * In the past the compiler handled loops built with LOOP_EXPR better
 >   than it handled loops built "by hand" out of GOTO_EXPRs.  My
 >   understanding is that this has changed since tree-ssa.  The issue
 >   here was that we made no attempt to rebuild a LOOP_EXPR from java
 >   bytecode.
 > 
 > * The .java front end could do a "constant array" optimization.  This
 >   optimization has not worked for quite some time (there's a PR).  In
 >   any case we could implement this for bytecode if it matters.
 > 
 > * The .java front end could more efficiently handle class literals.
 >   With the new 1.5 'ldc' bytecode extension, this is no longer a
 >   problem.
 > 
 > In other words, as far as I can remember, our old reasons for wanting
 > this are obsolete.

True, but there is still some information lost when going via the
.class format.  Per mentions debugging information, but there are some
other problems.  In particular, the type system and the rules for
exception regions are different.  Also, a "slot" in the .class format
doesn't necessarily correspond to a variable in the source language.
We work around all of this fairly sccessfully, but from an engineering
POV it's something of a kludge.

 > I think our technical approach should be to have ecj emit class files,
 > which would then be compiled by jc1.  In particular I think we could
 > change ecj to emit a single .jar file.  This has a few benefits: it
 > would give -save-temps meaning for gcj, it would let us more easily
 > drop ecj into the existing specs mechanism, and it would require very
 > few changes to the upstream compiler.

I think that from a maintenance point of view this would be a PITA.
Also, as Per mentioned we'd need to extend the .class file format in a
non-standard way to get full debugging information.  In particular,
.class files don't contain the full pathnames to source files.

If we were starting from scratch it would be good to start with ecj.
But we aren't starting from scratch, and it looks to me as though gcjx
has the potential to be the best long-term route.

Andrew.