On 11/18/2010 09:23 AM, Mark Mitchell wrote: > On 11/11/2010 3:20 PM, Ian Lance Taylor wrote: >> On Sun, Oct 31, 2010 at 12:09 PM, Ian Lance Taylor <i...@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 made it pretty clear that as long as the autotesters build java, and I get emails when something breaks, and you have the obligation to fix whatever broke, I have no objection. Andrew.