Re: PATCH RFA: Do not build java by default

Re: PATCH RFA: Do not build java by default

[Steven Bosscher]

Hello,

Ian Lance Taylor wrote:
> 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.

The argument against disabling java as a default language always was
that there should be at least one default language that requires
non-call exceptions. I recall testing many patches without trouble if
I did experimental builds with just C, C++, and Fortran, only to find
lots of java test suite failures in a complete bootstrap+test cycle.
So the second point is, IMVHO, not really true.

Is it possible to build and test java without all of libjava?

Ciao!
Steven

Re: PATCH RFA: Do not build java by default

[Gerald Pfeifer]

On Sun, 31 Oct 2010, Steven Bosscher wrote:
> Is it possible to build and test java without all of libjava?

configure --disable-libgcj.  I have been using this for my daily
bootstraps for a while.

Gerald

Re: PATCH RFA: Do not build java by default

[Andrew Pinski]

On Sun, Oct 31, 2010 at 12:47 PM, Gerald Pfeifer <gerald@pfeifer.com> wrote:
> On Sun, 31 Oct 2010, Steven Bosscher wrote:
>> Is it possible to build and test java without all of libjava?
>
> configure --disable-libgcj.  I have been using this for my daily
> bootstraps for a while.

But it does not test java.  Since the java testsuite depends on libjava.

Thanks,
Andrew Pinski

Re: PATCH RFA: Do not build java by default

[Dave Korn]

On 01/11/2010 03:48, Andrew Pinski wrote:
> On Sun, Oct 31, 2010 at 12:47 PM, Gerald Pfeifer <gerald@pfeifer.com> wrote:
>> On Sun, 31 Oct 2010, Steven Bosscher wrote:
>>> Is it possible to build and test java without all of libjava?
>> configure --disable-libgcj.  I have been using this for my daily
>> bootstraps for a while.
> 
> But it does not test java.  Since the java testsuite depends on libjava.

  Indeed, it doesn't do anything at all.  There is no java testsuite (i.e.
nothing in gcc/testsuite/java.*).  There is only a libjava testsuite.

    cheers,
      DaveK

Re: PATCH RFA: Do not build java by default

[Geert Bosch]

On Oct 31, 2010, at 15:33, Steven Bosscher wrote:
> The argument against disabling java as a default language always was
> that there should be at least one default language that requires
> non-call exceptions. I recall testing many patches without trouble if
> I did experimental builds with just C, C++, and Fortran, only to find
> lots of java test suite failures in a complete bootstrap+test cycle.
> So the second point is, IMVHO, not really true.

Feel free to enable Ada. Builds and tests faster than Java, 
and is known to expose many more middle end bugs, including
ones that require non-call exceptions.

  -Geert

Re: PATCH RFA: Do not build java by default

[Joern Rennecke]

Quoting Geert Bosch <bosch@adacore.com>:

>
> On Oct 31, 2010, at 15:33, Steven Bosscher wrote:
>> The argument against disabling java as a default language always was
>> that there should be at least one default language that requires
>> non-call exceptions. I recall testing many patches without trouble if
>> I did experimental builds with just C, C++, and Fortran, only to find
>> lots of java test suite failures in a complete bootstrap+test cycle.
>> So the second point is, IMVHO, not really true.
>
> Feel free to enable Ada. Builds and tests faster than Java,
> and is known to expose many more middle end bugs, including
> ones that require non-call exceptions.

But to get that coverage, testers will need to have gnat installed.
Will that become a requirement for middle-end patch regression testing?

Re: PATCH RFA: Do not build java by default

[Geert Bosch]

On Nov 1, 2010, at 00:30, Joern Rennecke wrote:
>> Feel free to enable Ada. Builds and tests faster than Java,
>> and is known to expose many more middle end bugs, including
>> ones that require non-call exceptions.
> 
> But to get that coverage, testers will need to have gnat installed.
> Will that become a requirement for middle-end patch regression testing?

No, the language will only be built if a suitable bootstrap compiler
is present. 

  -Geert

Re: PATCH RFA: Do not build java by default

[Joern Rennecke]

Quoting Geert Bosch <bosch@adacore.com>:

> On Nov 1, 2010, at 00:30, Joern Rennecke wrote:
>> But to get that coverage, testers will need to have gnat installed.
>> Will that become a requirement for middle-end patch regression testing?
>
> No, the language will only be built if a suitable bootstrap compiler
> is present.

I know that.  My question was aimed at soliciting opinions on patch
submission policy in the case that libjava build & testing are dropped
from standard bootstrap tests.

Re: PATCH RFA: Do not build java by default

[Paolo Bonzini]

On 11/01/2010 11:47 AM, Joern Rennecke wrote:
> Quoting Geert Bosch <bosch@adacore.com>:
>
>> On Nov 1, 2010, at 00:30, Joern Rennecke wrote:
>>> But to get that coverage, testers will need to have gnat installed.
>>> Will that become a requirement for middle-end patch regression testing?
>>
>> No, the language will only be built if a suitable bootstrap compiler
>> is present.
>
> I know that. My question was aimed at soliciting opinions on patch
> submission policy in the case that libjava build & testing are dropped
> from standard bootstrap tests.

You already need to have ecj installed, so it's one dependency more and 
one less.

Paolo

Re: PATCH RFA: Do not build java by default

[David Daney]

On 11/02/2010 03:48 AM, Paolo Bonzini wrote:
> On 11/01/2010 11:47 AM, Joern Rennecke wrote:
>> Quoting Geert Bosch <bosch@adacore.com>:
>>
>>> On Nov 1, 2010, at 00:30, Joern Rennecke wrote:
>>>> But to get that coverage, testers will need to have gnat installed.
>>>> Will that become a requirement for middle-end patch regression testing?
>>>
>>> No, the language will only be built if a suitable bootstrap compiler
>>> is present.
>>
>> I know that. My question was aimed at soliciting opinions on patch
>> submission policy in the case that libjava build & testing are dropped
>> from standard bootstrap tests.
>
> You already need to have ecj installed, so it's one dependency more and
> one less.

I may be mistaken, but I don't think that is true.  Building and testing 
of libgcj *does not* require ecj.

David Daney

Re: PATCH RFA: Do not build java by default

[Tom Tromey]

>>>>> "Steven" == Steven Bosscher <stevenb.gcc@gmail.com> writes:

Steven> The argument against disabling java as a default language always was
Steven> that there should be at least one default language that requires
Steven> non-call exceptions. I recall testing many patches without trouble if
Steven> I did experimental builds with just C, C++, and Fortran, only to find
Steven> lots of java test suite failures in a complete bootstrap+test cycle.
Steven> So the second point is, IMVHO, not really true.

Is it possible to convert all failures of this form into a C++ test case
with -fnon-call-exceptions?  If so then at least there is a way to add
regression tests.

Steven> Is it possible to build and test java without all of libjava?

As far as I'm aware, not at present.  I think even the minimal possible
subset of libjava is pretty big, on the order of hundreds of classes,
IIRC.

Tom

Re: PATCH RFA: Do not build java by default

[Andrew Haley]

On 11/01/2010 05:50 PM, Tom Tromey wrote:
>>>>>> "Steven" == Steven Bosscher <stevenb.gcc@gmail.com> writes:
> 
> Steven> The argument against disabling java as a default language always was
> Steven> that there should be at least one default language that requires
> Steven> non-call exceptions. I recall testing many patches without trouble if
> Steven> I did experimental builds with just C, C++, and Fortran, only to find
> Steven> lots of java test suite failures in a complete bootstrap+test cycle.
> Steven> So the second point is, IMVHO, not really true.
> 
> Is it possible to convert all failures of this form into a C++ test case
> with -fnon-call-exceptions?  If so then at least there is a way to add
> regression tests.

In practice, no.  We don't know what the C++ equivalent is until we've
seen the Java (or Ada) test failure.  In the Rumsfeld epistemology it's
an unknown uknown, something that we don't know we don't know.

> Steven> Is it possible to build and test java without all of libjava?
> 
> As far as I'm aware, not at present.  I think even the minimal possible
> subset of libjava is pretty big, on the order of hundreds of classes,
> IIRC.

And the failures I've seen have been in some of the crazy cases, not
just simple Java code, where things get complicated.

Andrew.

PATCH RFA: Do not build java by default

[Ian Lance Taylor]

[-- Attachment #1: Type: text/plain, Size: 1880 bytes --]

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.



[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: java --]
[-- Type: text/x-diff, Size: 1520 bytes --]

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

Re: PATCH RFA: Do not build java by default

[Andrew Haley]

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.

Re: PATCH RFA: Do not build java by default

[Laurent GUERBY]

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

Re: PATCH RFA: Do not build java by default

[Tom Tromey]

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

Re: PATCH RFA: Do not build java by default

[Dave Korn]

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

Re: PATCH RFA: Do not build java by default

[Ian Lance Taylor]

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

Re: PATCH RFA: Do not build java by default

[Diego Novillo]

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.

Re: PATCH RFA: Do not build java by default

[Andrew Haley]

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.

Re: PATCH RFA: Do not build java by default

[H.J. Lu]

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.


-- 
H.J.

Re: PATCH RFA: Do not build java by default

[Jeff Law]

  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

Re: PATCH RFA: Do not build java by default

[H.J. Lu]

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


-- 
H.J.

Re: PATCH RFA: Do not build java by default

[Eric Botcazou]

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

-- 
Eric Botcazou

Re: PATCH RFA: Do not build java by default

[Tom Tromey]

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

Re: PATCH RFA: Do not build java by default

[Jeff Law]

  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

Re: PATCH RFA: Do not build java by default

[Matthias Klose]

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

Re: PATCH RFA: Do not build java by default

[Ian Lance Taylor]

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

Re: PATCH RFA: Do not build java by default

[Mark Mitchell]

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,

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713

Re: PATCH RFA: Do not build java by default

[Andrew Haley]

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.

Re: PATCH RFA: Do not build java by default

[H.J. Lu]

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


-- 
H.J.

Re: PATCH RFA: Do not build java by default

[Mark Mitchell]

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,

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713

Re: PATCH RFA: Do not build java by default

[Diego Novillo]

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.

Re: PATCH RFA: Do not build java by default

[Jeff Law]

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

Re: PATCH RFA: Do not build java by default

[Ian Lance Taylor]

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

Re: PATCH RFA: Do not build java by default

[Dave Korn]

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

Re: PATCH RFA: Do not build java by default

[Mark Wielaard]

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