gcj and jikes
Fri May 2 22:19:00 GMT 2003
Joerg Brunsmann wrote:
> And it doesn't follow that it's more likely that someone will do the task
> (adding generic support to a front end) if gcj is using the old yacc
> based front end.
That is not what my concern is. My question is: are there or are
there likely to be any other Free Java compilers besides Jikes that
are likey to have/get better support for the new features? I can
imagine compiler researchers wanting to implement an extended Java,
and while they might use Jikes as a starting point, some might not.
For example, Nice (fttp://nice.sourceforge.net/) is a language
that is loosely an extended Java, including parametric types.
It is written in Java (and uses the Kawa framework) so there might
be some bootstrapping concerns using it in Gcc, but worst-case
it may be easier to manually convert a program from one language to
another than to implement complex features from scratch.
I'm just using Nice as an example; my point isn't that Nice is
the answer, but that we should do some research before deciding
on Jikes. If nothing else Nice's author may be a useful resource
on implementation strategies for extended Java compilers.
> There are two different tasks: a) adding generic support to a front end,
> b) integrate jikes front end into gcj. Both tasks could be done independently
> in parallel. You think the time is bad because the work done for tasks a) and
> b) have to be merged after finishing and this merging could be avoided if a)
> was done before b).
My bigger concern is that it might take a long time (possibly forever)
before somebody does a quality implementation of (a). If there is some
other quality implementation of (a) we could have used, then any effort
we have spent on (b) will have been wasted.
> To set the ball rolling let's try to answer if the licenses are compatible or
> can be made compatible. If not, there's no need to discuss this topic anymore.
Certainly let's do that.
More information about the Java