From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 102234 invoked by alias); 20 Aug 2015 15:52:58 -0000 Mailing-List: contact java-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: java-patches-owner@gcc.gnu.org Received: (qmail 102213 invoked by uid 89); 20 Aug 2015 15:52:58 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=AWL,BAYES_50,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=no version=3.3.2 X-Spam-User: qpsmtpd, 2 recipients X-HELO: mx4-phx2.redhat.com Received: from mx4-phx2.redhat.com (HELO mx4-phx2.redhat.com) (209.132.183.25) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Thu, 20 Aug 2015 15:52:57 +0000 Received: from zmail17.collab.prod.int.phx2.redhat.com (zmail17.collab.prod.int.phx2.redhat.com [10.5.83.19]) by mx4-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id t7KFqtmX004851; Thu, 20 Aug 2015 11:52:55 -0400 Date: Thu, 20 Aug 2015 15:52:00 -0000 From: Andrew Hughes To: Andrew Haley Cc: Matthias Klose , Tom Tromey , Jeff Law , Uros Bizjak , gcc-patches@gcc.gnu.org, java-patches@gcc.gnu.org Message-ID: <753848288.13346990.1440085975680.JavaMail.zimbra@redhat.com> In-Reply-To: <55D5F1C8.7060003@redhat.com> References: <87mvxxdxys.fsf@tromey.com> <141970419.12686720.1440038099721.JavaMail.zimbra@redhat.com> <87y4h68tk3.fsf@tromey.com> <55D58ED0.1020402@ubuntu.com> <55D5909B.3080207@redhat.com> <401143105.13318272.1440082676204.JavaMail.zimbra@redhat.com> <55D5F1C8.7060003@redhat.com> Subject: Re: [PATCH, libjava/classpath]: Fix overriding recipe for target 'gjdoc' build warning MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2015-q3/txt/msg00028.txt.bz2 ----- 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