Technical approach.
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:
A couple of other factors:
* Compile time. It is at least potentially faster to compile directly
to trees. However, this is negated in many cases since you want to
generate both bytecoe and native code. (This include libgcj.)
So generating bytecode first and then generating native code from
the bytecode is actually faster.
* Debugging. Historically Java degugging information is pretty limited.
Even with the latest specifications there is (for example) no support
for column numbers. However, the classfile format is extensible, and
so if needed we can define extra "attribute" sections.
* The .classfile format is quite inefficient. For example there is
no sharing of "symbols" between classes, so there is a lot of
duplication. However, this is a problem we share with everybody
else, and it could be solved at the bytecode level, co-operating
with other parties, iseally as a Java Specification Request.
An alternative approach would be to directly link ecj to the gcc back
end. However, this looks like significantly more work, requiring much
more hacking on the internals of the upstream compiler. I suspect
that this won't be worth the effort.
I think you're right. It could be a project for somebody to tackle
later.
ecj is written in java. This will complicate the bootstrap process.
However, the situation will not be quite as severe as the Ada
situation, in that it ought to be possible to bootstrap gcj using any
java runtime, including mini ones such as JamVM -- at least, assuming
that the suggested implementation route is taken.
I don't a "mini java runtime" would be useful. We could offer two
bootstrap solution:
(1) An existing (installed) Java run-time, which would be an older
version of gcj.
(2) A bytecode versions of ecj. This is only useful if we also make
available a bytecode version of libgcj, I think.
--
--Per Bothner
[EMAIL PROTECTED] http://per.bothner.com/
