Compiling Java with Eclipse [was: Converting GCC to compilation with C++]

[Per Bothner]

Tom Tromey wrote:

> I would love to have used Eclipse's front end, or jikes for that
> matter.  Eclipse's front end has the big advantage that there are
> people working on it full-time.  Unfortunately, as I understand it,
> the CPL is not GPL-compatible.  Also, I couldn't picture the FSF
> accepting a front end not owned by them.

The question is:

Is it practical technically to replace our Java front-end by ecj?
Of course there is always the option of using ecj as a separate pass,
and have jc1 just parse byte-code, but there are disadvantages:
* Implementing java->native as java->bytecode + bytecode->native
takes more compilation type.  However, in most cases you'll want
bytecode as well anyway (we certainly do for libgcj), in which
teh solution is to change the Makefile to generate bytecode first.
* It is more difficult to generate comprehensive debugging information
(e.g. column numbers), with adding non-standard extensions/attributes.
* More difficult to generate optimal code (as there are opimization
opportunities that are harder to recgnize in bytecode that in source).
However, we do want to do the best we can for optimizin bytecode, so
the solution is to do a better job of recognizing optimizable patterns
in bytecode.

So the question is:  Would using Eclipse's compiler be worth the
technical, legal, and political hurdles?  You mentioned:

* The CPL is not GPL-compatible.  I don't see the Eclipse license
mentioned at http://www.gnu.org/licenses/license-list.html, but a quick
glance indicates it isn't GPL-incompatible, and it doesn't appear to
be possible to fix it.  However, Eclipse might be willing to
dual-license their compiler.

Strictly speaking, the license doesn't have to get GPL-comptiable it
we just use the compiler as a independent pre-processor, but that's
not a good solution, and I doubt the FSF would go for it.

* The FSF doesn't own the copyright on the Eclipse compiler.  That's
a concern, but there are precedents.  For example, it doesn't own
the copyrights on boehm-gc, nor on all of libiberty.  The primary
reason the FSF wants copyright is to be able to enforce copyright;
Eclipse certainly has the resources to enforce its own copyrights.

So it boils down to:  can you make a strong enough technical case that
using the Eclipse compiler would benefit us, to justify the effort
needed to work on the legal and political issues?

Let's assume we'd use ecj standaline, as a separate pass, since the
technical hurdles are a lot less.  It would be helpful if someone
would write
(1) a patch to gcj that uses ecj when compiling from source.
(2) (optionally) a patch to libjava that builds the native code
files by using the previously-built .class files, rather than
from source.

How does this effect bootstrap times - it would be best to have
numbers for both (1) and (1+2) in comparison to the current times.

And how does this change the quality of generated code as well
as debugability (with gdb) of generated code?

How does this effect the testsuite, especially jaxx?  If someone
has access to Sun's testsuites (and the license permits such a
test), it would be helpful to run that as well.
-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/