From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6209 invoked by alias); 18 Nov 2010 09:23:47 -0000 Received: (qmail 6176 invoked by uid 22791); 18 Nov 2010 09:23:45 -0000 X-SWARE-Spam-Status: No, hits=-1.7 required=5.0 tests=AWL,BAYES_00,TW_IB,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 18 Nov 2010 09:23:40 +0000 Received: (qmail 11596 invoked from network); 18 Nov 2010 09:23:38 -0000 Received: from unknown (HELO ?192.168.0.105?) (mitchell@127.0.0.2) by mail.codesourcery.com with ESMTPA; 18 Nov 2010 09:23:38 -0000 Message-ID: <4CE4F09F.7010605@codesourcery.com> Date: Thu, 18 Nov 2010 09:23:00 -0000 From: Mark Mitchell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: Ian Lance Taylor CC: gcc@gcc.gnu.org, java@gcc.gnu.org, gcc-patches@gcc.gnu.org, java-patches@gcc.gnu.org Subject: Re: PATCH RFA: Do not build java by default References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Mailing-List: contact java-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: java-owner@gcc.gnu.org X-SW-Source: 2010-11/txt/msg00029.txt.bz2 On 11/11/2010 3:20 PM, Ian Lance Taylor wrote: > On Sun, Oct 31, 2010 at 12:09 PM, Ian Lance Taylor 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. Thank you, -- Mark Mitchell CodeSourcery mark@codesourcery.com (650) 331-3385 x713