FYI: submitted ecj patch upstream

[Tom Tromey]

Tom> I looked at writing an "ecj1" driver that does a pure translation of
Tom> command-line arguments, but I don't think that is possible due to our
Tom> need to differentiate between "primary" and "dependency" classes on
Tom> the output end.

>> Like I said, I don't think it is possible.

Andrew> Why?  I don't see why you think it needs to be written in Java.

It has nothing to do with the language that the wrapper is written
in.  It has to do with the needs of jc1 when using the C++ ABI.

Suppose we have 'class A extends B { ... }'.  If we just compile
A.java, we will need information about class B in order to compute the
size of A.  But if we haven't already compiled to .class, we can't get
this info.  With the GCCMain driver, we arrange for these dependent
classes to be emitted separate -- so we can read them for information,
but not emit object code for them.

Andrew> See now we are getting into the problems with the ecj merge, there are
Andrew> going to be too many dependecies.  You forget to mention you also
Andrew> need a JVM also.

Yes, you need a bootstrap JVM.  I didn't mention this because it is
not relevant to the question at hand.

Andrew> So now we have somewhere between 1-3 plus driver scripts plus
Andrew> the JVM which can be a pain in the butt to install on say a
Andrew> powerpc Linux box because there is no JVM that exists to begin
Andrew> without gcj.

There's kaffe and jamvm, and probably others.

I know from extensive discussions on irc that you're against this
merge.  You'll have plenty of chances to object to it when stage 1
opens.  Meanwhile I'd prefer it if we could keep this thread on track,
namely, figuring out how to solve this problem in the best way
possible.

Tom