Re: PATCH RFA: Do not build java by default

[Ian Lance Taylor <iant@google.com>]

Mark Mitchell <mark@codesourcery.com> writes:

> On 11/11/2010 3:20 PM, Ian Lance Taylor wrote:
>> On Sun, Oct 31, 2010 at 12:09 PM, Ian Lance Taylor <iant@google.com> wrote:
>>> Currently we build the Java frontend and libjava by default.  At the GCC
>>> Summit we raised the question of whether should turn this off, thus only
>>> building it when java is explicitly selected at configure time with
>>> --enable-languages.  Among the people at the summit, there was general
>>> support for this, and nobody was opposed to it.
>
>> I count 33 messages on the topic and it is clear that there is no
>> consensus.  I am withdrawing this proposed patch.
>
> I think that's a mistake.
>
> The arguments raised, such as the fact that Java tests non-call
> exceptions, are just not persuasive to me.  If we need tests for a
> middle-end feature, we can almost always write them in C or C++.
>
> The bottom line is that libjava takes a very long time to build and that
> the marginal benefit is out of proportion to the cost.  Building
> zillions of Java class files cannot be the best way to test non-call
> exceptions.  If we have no tests for non-call exceptions in the C/C++
> testsuite, perhaps you (Ian) could write a few in C++?
>
> Ian, I was prepared to approve the patch.  I certainly won't do that if
> you now think it's a bad idea, but if you still think it's a good idea,
> I think you should go for it.
>
> I think that it should still be the case that if you break Java, and one
> of the Java testers catches you, you still have an obligation to fix the
> problem.  All we're changing is whether you build Java by default;
> nothing else.

I still think it would be a good idea to remove Java from the set of
languages which are built by default.  What I meant by withdrawing the
patch is that I felt that we needed consensus and I don't feel that we
have it.  I wrote the patch to express what I felt was the sense of the
discussion of the summit, so that the idea wasn't simply dropped.

Andrew has asked for autotesters for Java; I don't run any autotesters
and I don't want to sign up for that.  Can somebody volunteer for that?
Presumably anybody currently running an autotester could add an explicit
--enable-languages option with java.  Andrew has also asked to receive
e-mail when there is a Java bug.

I count 38 existing tests for -fnon-call-exceptions with C/C++ in the
testsuite.  We could also get more coverage by adding
-fnon-call-exceptions to the list of testsuite torture options, though
that would of course slow down running the torture testsuite.  Any
opinions?

At this point does anybody strongly object to committing the patch.

Ian