Re: [PATCH, libjava/classpath]: Fix overriding recipe for target 'gjdoc' build warning

[Andrew Hughes <gnu.andrew@redhat.com>]

----- Original Message -----
> On 08/20/2015 03:57 PM, Andrew Hughes wrote:
> > ----- Original Message -----
> >> On 20/08/15 09:24, Matthias Klose wrote:
> >>> On 08/20/2015 06:36 AM, Tom Tromey wrote:
> >>>> Andrew> No, it isn't. It's still a necessity for initial bootstrapping
> >>>> of
> >>>> Andrew> OpenJDK/IcedTea.
> >>>>
> >>>> Andrew Haley said the opposite here:
> >>>>
> >>>> https://gcc.gnu.org/ml/gcc-patches/2015-08/msg00537.html
> >>>
> >>> if you need bootstrapping OpenJDK 6 or OpenJDK 7, then having gcj
> >>> available for the target platform is required. Starting with OpenJDK
> >>> 8 you should be able to cross build OpenJDK 8 with an OpenJDK 8
> >>> available on the cross platform.  It might be possible to cross
> >>> build older OpenJDK versions, but this usually is painful.
> >>
> >> Sure, but we don't need GCJ going forward.  I don't think that there
> >> are any new platforms to which OpenJDK has not been ported which will
> >> require GCJ to bootstrap.  And even if there are, anybody who needs to
> >> do that can (and, indeed, should) use an earlier version of GCJ.  It's
> >> not going to go away; it will always be in the GCC repos.  And because
> >> newer versions of GCC may break GCJ (and maybe OpenJDK) it makes more
> >> sense to use an old GCC/GCJ for the bootstrapping of an old OpenJDK.
> > 
> > I don't see how we don't at present. How else do you solve the
> > chicken-and-egg situation of needing a JDK to build a JDK? I don't
> > see crossing your fingers and hoping there's a binary around
> > somewhere as a very sustainable system.
> 
> That's what we do with GCC, binutils, etc: we bootstrap.
> 

True, but it's more amenable to cross-compilation than older versions
of OpenJDK. I guess we've been riding on the fact that we have gcc
available at an early stage on new systems and this allows us to get
easily to gcj and from there to IcedTea.

> > From a personal point of view, I need gcj to make sure each new
> > IcedTea 1.x and 2.x release bootstraps.
> 
> Sure, but all that does is test that the GCJ bootstrap still works.
> And it's probably the only serious use of GCJ left.
> 

Yes, but that's a feature I'm reluctant to suddenly drop in the late
stages of these projects.

We don't have it in IcedTea 3.x / OpenJDK 8 and so that usage will
go when we drop support for 7.

> > I don't plan to hold my system GCC at GCC 5 for the next decade or
> > however long we plan to support IcedTea 2.x / OpenJDK 7. It's also
> > still noticeably faster building with a native ecj than OpenJDK's
> > javac.  It would cause me and others a lot of pain to remove gcj at
> > this point. What exactly is the reason to do so, other than some
> > sudden whim?
> 
> It's not a sudden whim: it's something we've been discussing for years.
> The only reason GCJ is still alive is that I committed to keep it
> going while we still needed it boot bootstrap OpenJDK.  Maintaining
> GCJ in GCC is a significant cost, and GCJ has reached the end of its
> natural life.  Classpath is substantially unmaintained, and GCJ
> doesn't support any recent versions of Java.

Ok, I wasn't aware of this work. I follow this list but the only patches
I've really seen here are the occasional bumps from Matthias.

I don't want to keep it around forever either. Is there a way we can
stage the removal rather than going for a straight-out deletion so
dependants have more time to adapt to this? For example, can we flag
it as deprecated, take it out of defaults and the testsuite, etc. but
leave the code there at least for a little while longer? Basically,
whatever is needed to stop it being a burden to GCC developers without
removing it altogether.

Classpath is not unmaintained and has equally been kept going by me
over the years for similar reasons. It is overdue a merge into gcj
and I've been putting that off, both for want of a suitable point
to do so and the need to deal with the mess that is Subversion.

If gcj can be just kept around for a few more years, while the older
IcedTeas also wind down, I'll do whatever work is needed to keep it
going for my purposes, then we can finally remove it. But dropping it
altogether in the next six months is just too soon.

> 
> Andrew.
> 
-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222

PGP Key: rsa4096/248BDC07 (hkp://keys.gnupg.net)
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F  8F91 3B96 A578 248B DC07