Re: 3.1 bootstrap failure in libjava

[Tom Tromey <tromey at redhat dot com>]

>>>>> "Brad" == Brad Lucier <lucier@math.purdue.edu> writes:

Brad> I think a technical argument can be made, just from the point of
Brad> view of an ignorant tester, that the Java port is not ready for
Brad> prime time.

I have a few things to say about this.

First, on the trunk you may be right.  The Java group is an order of
magnitude smaller than the rest of gcc.  Our efforts, especially those
of us working on Java at Red Hat, have largely been focussed on the
3.0 branch.  That's because we think the 3.0 branch is the most
important place to put our limited resources -- we want gcc 3.0 to
include a solid gcj.

If you are talking about the branch, then I disagree strongly.  Has
Java been broken at times?  Sure.  However, we've also gone through
periods of time where problems in the C++ compiler caused Java not to
build.  That isn't an argument to disable C++ though.  It is an
argument to make it work.  And on the branch we've tried very hard to
do that.

I don't remember the last time the branch Java failed to build for me.
I build it regularly on Solaris, x86 Linux, and PPC Linux.  Until this
week, for a week or two I updated, built, and ran `make check' every
single day.

Finally, I think "prime time" means different things on the trunk and
on the branch.  While I think that ideally both would bootstrap
perfectly all the time, it is clear we don't live in that perfect of a
world.  The branch has to be better than the trunk, so that is what we
try to work on.

Can we do better on the trunk than we do now?  Sure.  But I think
disabling Java is a dangerous way to do this.  It puts us into a Catch
22: we can't enable Java until it is stable, but it will never be
stable if people making back end changes to gcc don't test it -- which
means enabling it.  As an example of this, just recently Andrew Haley
fixed a bug in the new EH code on the trunk.  This bug was revealed by
some code in libgcj, and as far as I know by nothing else.  If we
disable Java then this sort of thing will happen all the time.

This situation is just going to get worse as we add more front ends to
the gcc repository.  Mark's plan of disconnecting the front and back
ends sounds good to me (from my position of utter ignorance :-), but
it is a sad fact that the maintainers who would most benefit from this
-- those working on the less popular front ends -- are also the least
likely to have the manpower to implement it.

Tom