Patchwork PATCH RFA: Do not build java by default

login
register
mail settings
Submitter Ian Taylor
Date Oct. 31, 2010, 7:09 p.m.
Message ID <mcrocaa18nt.fsf@google.com>
Download mbox | patch
Permalink /patch/69734/
State New
Headers show

Comments

Ian Taylor - Oct. 31, 2010, 7:09 p.m.
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.

Here is a patch which implements that.  I'm sending this to the mailing
lists gcc@ and java@, as well as the relevant -patches@ lists, because
it does deserve some broader discussion.

This is not a proposal to remove the Java frontend nor is it leading up
to that.  It is a proposal to not build the frontend by default, putting
Java in the same category as Ada and Objective C++.  The main argument
in favor of this proposal is twofold: 1) building libjava is a large
component of gcc bootstrap time, and thus a large component in the
amount of time it takes to test changes; 2) it is in practice very
unusual for middle-end or back-end changes to cause problems with Java
without also causing problems for C/C++, thus building and testing
libjava does not in practice help ensure the stability of the compiler.
A supporting argument is since Sun has released their Java tools under
the GPL, community interest seems to have shifted toward the Sun tools;
gcc's Java frontend is in maintenance mode, with little new development
currently planned.

This patch should not of course change whether or not distros choose to
package the Java compiler; undoubtedly they would continue to do so,
just as they package the Ada compiler today.

Comments?  Approvals?

Ian


gcc/java/ChangeLog:

2010-10-31  Ian Lance Taylor  <iant@google.com>

	* config-lang.in (build_by_default): Set to no.

gcc/ChangeLog:

2010-10-31  Ian Lance Taylor  <iant@google.com>

	* doc/install.texi (Configuration): Note in two places that Java
	is not enabled by default.
Andrew Haley - Nov. 1, 2010, 8:59 a.m.
On 10/31/2010 07:09 PM, Ian Lance Taylor wrote:

> This patch should not of course change whether or not distros choose to
> package the Java compiler; undoubtedly they would continue to do so,
> just as they package the Ada compiler today.
> 
> Comments?  Approvals?

I see your point, but this will lead to some quality regressions in gcc
itself.  libgcj is a good stress test for gcc, and has revealed some
bugs in the past.  It might be possible to mitigate some of this with
autotesters that run a full libgcj bootstrap every night.

Andrew.
Dave Korn - Nov. 1, 2010, 10:54 a.m.
On 31/10/2010 19:09, Ian Lance Taylor wrote:

> Java in the same category as Ada and Objective C++.  The main argument
> in favor of this proposal is twofold: 1) building libjava is a large
> component of gcc bootstrap time, and thus a large component in the
> amount of time it takes to test changes; 

  Proposing to change the compiler as a solution to that problem seems to be a
category error to me.  You can achieve the same end-result by social rather
than technical means: just change the rules for patch submission to say "You
don't have to test your patch against Java".

> 2) it is in practice very
> unusual for middle-end or back-end changes to cause problems with Java
> without also causing problems for C/C++, 

  This seems like false reasoning as well.  It may (or may not - I don't
suppose anyone's actually done the number on this, have they?) be unusual, but
the bugs that meet this criterion are nonetheless real bugs that we do not
want to put into our compiler if we can possibly help it, they will
subsequently need discovering, analysing and fixing, and will require manpower
and resources to do so.

  I find it hard not to expect that the long-term outcome will be a gradual
decline in quality of gcj if we do this.  Particularly on minority platforms,
which are exactly the ones that have the least manpower available to fix problems.

  For these reasons, my "vote" is against making this change.

    cheers,
      DaveK
Ian Taylor - Nov. 1, 2010, 5:35 p.m.
Dave Korn <dave.korn.cygwin@gmail.com> writes:

> On 31/10/2010 19:09, Ian Lance Taylor wrote:
>
>> Java in the same category as Ada and Objective C++.  The main argument
>> in favor of this proposal is twofold: 1) building libjava is a large
>> component of gcc bootstrap time, and thus a large component in the
>> amount of time it takes to test changes; 
>
>   Proposing to change the compiler as a solution to that problem seems to be a
> category error to me.  You can achieve the same end-result by social rather
> than technical means: just change the rules for patch submission to say "You
> don't have to test your patch against Java".

I think the two statements are essentially equivalent.  These days, when
most ordinary users get their compiler from a distro or other binary
form, the set of default languages is most important for gcc developers.
We currently say that for middle-end or backend patches you must
bootstrap with all default languages.  Changing the set of default
languages is a way of changing that statement.  It's not, in my opinion,
a category error.

Ian
Diego Novillo - Nov. 1, 2010, 6:16 p.m.
On Sun, Oct 31, 2010 at 15:09, Ian Lance Taylor <iant@google.com> wrote:

> Comments?  Approvals?

FWIW, I agree with this patch for the same reasons stated by Ian.
Other than massively increasing build times, I have not seen
substantial benefits for having java enabled by default.  Ada, on the
other hand, has shown more usefulness in exposing bugs (particularly,
middle end) and is many times faster.

This is the kind of patch that requires more consensus or agreement
from the java maintainers.  aph, are you dead set against disabling
java?  Is there anything we could do to change your mind?


Thanks.  Diego.
Andrew Haley - Nov. 1, 2010, 6:58 p.m.
On 11/01/2010 06:16 PM, Diego Novillo wrote:
> On Sun, Oct 31, 2010 at 15:09, Ian Lance Taylor <iant@google.com> wrote:
> 
>> Comments?  Approvals?
> 
> FWIW, I agree with this patch for the same reasons stated by Ian.
> Other than massively increasing build times, I have not seen
> substantial benefits for having java enabled by default.  Ada, on the
> other hand, has shown more usefulness in exposing bugs (particularly,
> middle end) and is many times faster.
> 
> This is the kind of patch that requires more consensus or agreement
> from the java maintainers.  aph, are you dead set against disabling
> java?

No.

> Is there anything we could do to change your mind?

Yes, if we have an autotester that runs the libgcj test suite and
mails maintainers (or the list) when they break things.

Andrew.
H.J. Lu - Nov. 1, 2010, 7:34 p.m.
On Mon, Nov 1, 2010 at 11:58 AM, Andrew Haley <aph@redhat.com> wrote:
>
>> Is there anything we could do to change your mind?
>
> Yes, if we have an autotester that runs the libgcj test suite and
> mails maintainers (or the list) when they break things.
>

I don't mind enabling Java in my autotesters for Linux/ia32 and
Linux/x86-64.
Jeff Law - Nov. 2, 2010, 3:39 a.m.
On 11/01/10 12:16, Diego Novillo wrote:
> On Sun, Oct 31, 2010 at 15:09, Ian Lance Taylor<iant@google.com>  wrote:
>
>> Comments?  Approvals?
> FWIW, I agree with this patch for the same reasons stated by Ian.
> Other than massively increasing build times, I have not seen
> substantial benefits for having java enabled by default.  Ada, on the
> other hand, has shown more usefulness in exposing bugs (particularly,
> middle end) and is many times faster.
>
> This is the kind of patch that requires more consensus or agreement
> from the java maintainers.  aph, are you dead set against disabling
> java?  Is there anything we could do to change your mind?
Building libjava (at least for me) is primarily painful due to 2 files 
(the names escape me) and the rather poor coarse level parallelism 
(can't build the 32bit and 64bit multilibs in parallel for example).

Has anyone looked at fixing the build machinery for libjava to make it 
more sensible?

I'd personally prefer java over ada as I'm able to understand java code 
easier, thus when something does go wrong I'm able to debug it much faster.

Jeff
H.J. Lu - Nov. 2, 2010, 3:58 a.m.
On Mon, Nov 1, 2010 at 8:39 PM, Jeff Law <law@redhat.com> wrote:
>  On 11/01/10 12:16, Diego Novillo wrote:
>>
>> On Sun, Oct 31, 2010 at 15:09, Ian Lance Taylor<iant@google.com>  wrote:
>>
>>> Comments?  Approvals?
>>
>> FWIW, I agree with this patch for the same reasons stated by Ian.
>> Other than massively increasing build times, I have not seen
>> substantial benefits for having java enabled by default.  Ada, on the
>> other hand, has shown more usefulness in exposing bugs (particularly,
>> middle end) and is many times faster.
>>
>> This is the kind of patch that requires more consensus or agreement
>> from the java maintainers.  aph, are you dead set against disabling
>> java?  Is there anything we could do to change your mind?
>
> Building libjava (at least for me) is primarily painful due to 2 files (the
> names escape me) and the rather poor coarse level parallelism (can't build
> the 32bit and 64bit multilibs in parallel for example).
>
> Has anyone looked at fixing the build machinery for libjava to make it more
> sensible?
>
> I'd personally prefer java over ada as I'm able to understand java code
> easier, thus when something does go wrong I'm able to debug it much faster.
>

FWIW, it takes about 33minutes to bootstap gcc trunk on Fedora 13/Intel
Core i7 870 with both 32bit and 64bit libraries. I configure gcc with

-enable-clocale=gnu --with-system-zlib --with-demangler-in-ld  --enab
le-shared --enable-threads=posix --enable-haifa  --prefix=/usr/gcc-4.6.0 --with-
local-prefix=/usr/local --with-fpmath=sse --with-plugin-ld=ld.gold --enable-gold
 --with-fpmath=sse
Matthias Klose - Nov. 2, 2010, 5:12 a.m.
On 31.10.2010 20:09, 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.
>
> Here is a patch which implements that.  I'm sending this to the mailing
> lists gcc@ and java@, as well as the relevant -patches@ lists, because
> it does deserve some broader discussion.
>
> This is not a proposal to remove the Java frontend nor is it leading up
> to that.  It is a proposal to not build the frontend by default, putting
> Java in the same category as Ada and Objective C++.  The main argument
> in favor of this proposal is twofold: 1) building libjava is a large
> component of gcc bootstrap time, and thus a large component in the
> amount of time it takes to test changes; 2) it is in practice very
> unusual for middle-end or back-end changes to cause problems with Java
> without also causing problems for C/C++, thus building and testing
> libjava does not in practice help ensure the stability of the compiler.
> A supporting argument is since Sun has released their Java tools under
> the GPL, community interest seems to have shifted toward the Sun tools;
> gcc's Java frontend is in maintenance mode, with little new development
> currently planned.

please note that gcj is still required for a bootstrap of openjdk on platforms 
which don't yet have a working openjdk. At least for this purpose it is still 
maintained.

> This patch should not of course change whether or not distros choose to
> package the Java compiler; undoubtedly they would continue to do so,
> just as they package the Ada compiler today.
>
> Comments?  Approvals?

if build speed is the only issue, why not

  - disable the static libgcj build, if not explicitely enabled?

  - disable the biarch build for libgcj? most distributions don't
    have all of the depending libraries available for biarch builds.

Matthias
Eric Botcazou - Nov. 2, 2010, 8:21 a.m.
> I'd personally prefer java over ada as I'm able to understand java code
> easier, thus when something does go wrong I'm able to debug it much faster.

If this can make any difference: even if Ada is enabled by default, we (I at 
least) will still be there to analyze hard-to-debug problems exposed by Ada.
Laurent GUERBY - Nov. 2, 2010, 10:13 a.m.
On Mon, 2010-11-01 at 08:59 +0000, Andrew Haley wrote:
> On 10/31/2010 07:09 PM, Ian Lance Taylor wrote:
> 
> > This patch should not of course change whether or not distros choose to
> > package the Java compiler; undoubtedly they would continue to do so,
> > just as they package the Ada compiler today.
> > 
> > Comments?  Approvals?
> 
> I see your point, but this will lead to some quality regressions in gcc
> itself.  libgcj is a good stress test for gcc, and has revealed some
> bugs in the past.  It might be possible to mitigate some of this with
> autotesters that run a full libgcj bootstrap every night.

Hi,

Let's imagine we have a reliable tool on a distributed build farm that
accepts set of patches (via mail and web with some authentification) and
does automatic regression testing and report on selected platform.

This would enable more ambitious in our testing requirements without
having developpers invest in powerful machines to avoid being slowed
down but would GCC developpers go as far as setting a requirement that
patches must be validated by such a tool before commit for example by
giving the URL of the tester result with suitable exceptions for trivial
patches and tester being unavailable or overloaded, etc...?

Sincerely,

Laurent
http://gcc.gnu.org/wiki/CompileFarm
Tom Tromey - Nov. 2, 2010, 3:35 p.m.
>>>>> "Jeff" == Jeff Law <law@redhat.com> writes:

Jeff> Building libjava (at least for me) is primarily painful due to 2 files
Jeff> (the names escape me) and the rather poor coarse level parallelism
Jeff> (can't build the 32bit and 64bit multilibs in parallel for example).

Jeff> Has anyone looked at fixing the build machinery for libjava to make it
Jeff> more sensible?

Nope.  AFAIK it is already as parallelized as possible, but it has been
a while since I looked at it.

I thought the really bad file (HTML_401F.java, IIRC) had some functions
split up so that it wasn't so evil any more.

The multilib thing sounds like a top-level problem of some kind.
At least, I don't recall that libjava does anything special here.

Tom
Tom Tromey - Nov. 2, 2010, 3:36 p.m.
>>>>> "Laurent" == Laurent GUERBY <laurent@guerby.net> writes:

Laurent> Let's imagine we have a reliable tool on a distributed build
Laurent> farm that accepts set of patches (via mail and web with some
Laurent> authentification) and does automatic regression testing and
Laurent> report on selected platform.

Can we have it for gdb as well?

Tom
Jeff Law - Nov. 2, 2010, 4:24 p.m.
On 11/02/10 09:35, Tom Tromey wrote:
>>>>>> "Jeff" == Jeff Law<law@redhat.com>  writes:
> Jeff>  Building libjava (at least for me) is primarily painful due to 2 files
> Jeff>  (the names escape me) and the rather poor coarse level parallelism
> Jeff>  (can't build the 32bit and 64bit multilibs in parallel for example).
>
> Jeff>  Has anyone looked at fixing the build machinery for libjava to make it
> Jeff>  more sensible?
>
> Nope.  AFAIK it is already as parallelized as possible, but it has been
> a while since I looked at it.
>
> I thought the really bad file (HTML_401F.java, IIRC) had some functions
> split up so that it wasn't so evil any more.
It's the libgcj_tools_la-tools which gets built twice for each 
architecture and its build seems to always fire off last and takes a few 
minutes for each compilation.

> The multilib thing sounds like a top-level problem of some kind.
> At least, I don't recall that libjava does anything special here.
Yea, I suspect the way multilibs are handled is far from ideal from a 
parallel make standpoint.  Fixing the underlying multilib goop may be 
ugly, but probably would have a nice benefit across the various runtime 
libraries we utilize.

jeff
Ian Taylor - Nov. 11, 2010, 11:20 p.m.
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.
>
> Here is a patch which implements that.  I'm sending this to the mailing
> lists gcc@ and java@, as well as the relevant -patches@ lists, because
> it does deserve some broader discussion.

I count 33 messages on the topic and it is clear that there is no
consensus.  I am withdrawing this proposed patch.

Ian
Mark Mitchell - Nov. 18, 2010, 9:23 a.m.
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.

Thank you,
Andrew Haley - Nov. 18, 2010, 10 a.m.
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 <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 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.
H.J. Lu - Nov. 18, 2010, 1:42 p.m.
On Thu, Nov 18, 2010 at 2:00 AM, Andrew Haley <aph@redhat.com> wrote:
> 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 <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 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.
>

FYI, this testsuite regression is only seen in libjava:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46515
Jeff Law - Nov. 18, 2010, 3:23 p.m.
On 11/18/10 02:23, 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<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.
> [ ... ]
>
> 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++?
To put this in perspective, eliminating java cuts my build cycle time by 
more than 50%.

> 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.
Agreed.  I'd really like to see java removed from the default languages; 
I just don't see the cost vs benefit justifies keeping java in the 
default languages.

Jeff
Mark Mitchell - Nov. 18, 2010, 3:37 p.m.
On 11/18/2010 2:00 AM, Andrew Haley wrote:

> 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.

Great.  In contrast to Ian's statement, then, I think we *do* have a
consensus: remove Java from default languages, but do leave it in
autotesters (with consequences as above).

Thank you,
Diego Novillo - Nov. 18, 2010, 4:02 p.m.
On Thu, Nov 18, 2010 at 07:37, Mark Mitchell <mark@codesourcery.com> wrote:
> On 11/18/2010 2:00 AM, Andrew Haley wrote:
>
>> 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.
>
> Great.  In contrast to Ian's statement, then, I think we *do* have a
> consensus: remove Java from default languages, but do leave it in
> autotesters (with consequences as above).

I agree as well.


Diego.
Ian Taylor - Nov. 18, 2010, 5:18 p.m.
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
Dave Korn - Nov. 18, 2010, 6:22 p.m.
On 18/11/2010 17:18, Ian Lance Taylor wrote:

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

  Nah, I've been persuaded by the arguments advanced and withdraw my previous
objection.

    cheers,
      DaveK
Mark Wielaard - Nov. 18, 2010, 8:52 p.m.
On Thu, 2010-11-18 at 09:18 -0800, Ian Lance Taylor wrote:
> 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.

We have a machine doing GCC builds for GNU Classpath. Are there scripts
for official autotesters that can automatically detect regressions and
send email to the right people?

Thanks,

Mark

Patch

Index: gcc/java/config-lang.in
===================================================================
--- gcc/java/config-lang.in	(revision 166080)
+++ gcc/java/config-lang.in	(working copy)
@@ -36,5 +36,7 @@  gtfiles="\$(srcdir)/java/java-tree.h \$(
 
 target_libs=${libgcj_saved}
 lang_dirs="fastjar"
-#build_by_default=no
 lang_requires=c++
+
+# Do not build java by default.
+build_by_default=no
Index: gcc/doc/install.texi
===================================================================
--- gcc/doc/install.texi	(revision 166080)
+++ gcc/doc/install.texi	(working copy)
@@ -1320,7 +1309,7 @@  Currently, you can use any of the follow
 Building the Ada compiler has special requirements, see below.
 If you do not pass this flag, or specify the option @code{all}, then all
 default languages available in the @file{gcc} sub-tree will be configured.
-Ada and Objective-C++ are not default languages; the rest are.
+Java, Ada and Objective-C++ are not default languages; the rest are.
 Re-defining @code{LANGUAGES} when calling @samp{make} @strong{does not}
 work anymore, as those language sub-directories might not have been
 configured!
@@ -1763,7 +1741,9 @@  tools.
 
 @subheading Java-Specific Options
 
-The following option applies to the build of the Java front end.
+The following option applies to the build of the Java front end.  Note
+that the Java front end is not built by default; in order to build it,
+use the @option{--enable-languages} option described above.
 
 @table @code
 @item --disable-libgcj