Re: [JAVA PATCH] Enable more array bounds check elimination
snip... > > At a very high level, you should be aware of a general belief that GCJ's > life is limited. There's been various calls to deprecate it. So > spending a lot of time optimizing GCJ's output may not be the best use > of your skills :-) > Unless things have changed since it was last discussed, the plan was for it to be deprecated in GCC 6 and removed in 7. If that's the case, these changes may sadly not see a release. It does seem that no-one has bitten the bullet of removing it yet though. -- 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
Re: [wwwdocs,Java] java/index.html -- fix formatting on gcc.gnu.org
- Original Message -
> It turns out the stricter server settings also broke the /java
> page on gcc.gnu.org.
>
> This restores showing two columns on this page (though it still
> uses non-standard CSS extensions).
>
>
> That said, looking at the page, and how since 2005 nearly all changes
> have been maintainance ones from me, is it really worthwhile keeping
> this (short of historic reasons)?
>
> 2016-04-08 Gerald Pfeifer
>
> * index.html: Replace manual style to establish two columns
> by new global CSS class "twocolumns".
>
> Index: gcc.css
> ===
> RCS file: /cvs/gcc/wwwdocs/htdocs/gcc.css,v
> retrieving revision 1.38
> diff -u -r1.38 gcc.css
> --- gcc.css 5 Apr 2016 16:20:29 - 1.38
> +++ gcc.css 9 Apr 2016 16:22:40 -
> @@ -15,6 +15,8 @@
> .highlight{ color: darkslategray; font-weight:bold; }
> .smaller { font-size: 80%; }
>
> +.twocolumns { column-counts:2; -moz-column-count:2; }
> +
> td.news { width: 50%; padding-right: 8px; }
> td.news h2 { font-size: 1.2em; margin-top: 0; margin-bottom: 2%; }
> td.news dl { margin-top:0; }
>
> Index: java/index.html
> ===
> RCS file: /cvs/gcc/wwwdocs/htdocs/java/index.html,v
> retrieving revision 1.177
> diff -u -r1.177 index.html
> --- java/index.html 27 Jun 2014 15:04:39 - 1.177
> +++ java/index.html 9 Apr 2016 16:22:41 -
> @@ -32,7 +33,7 @@
>
> GCJ News
>
> -
> +
>
>
>
>
I guess the next news will be the removal of GCJ during the
GCC 7 development period, so its remaining shelf life should
be limited anyway.
--
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
Re: [PATCH, libjava/classpath]: Fix overriding recipe for target 'gjdoc' build warning
- Original Message - > On August 20, 2015 7:35:37 PM GMT+02:00, Andrew Hughes > wrote: > >- Original Message - > >> snip... > >> > > >> > Having classpath (with binary files!) In the GCC SVN (or future > >git) > >> > repository is a significant burden, not to mention the size of the > >> > distributed source tarball. > >> > > >> > If we can get rid of that that would be a great step in reducing > >the > >> > burden. > >> > > >> > Iff we can even without classpath build enough of java to be useful > >(do you > >> > really need gcj or only gij for bootstrapping openjdk? After all > >ecj is > >> > just > >> > a drop-in to gcc as well). > >> > >> All the Java compilers are written in Java (ecj & javac). So to run > >them, you > >> need a JVM and its class library. > >> > >> It's those binary files which allow gcj to bootstrap the stack. If > >OpenJDK > >> had a minimal binary class library, it would be able to bootstrap > >itself. > >> > >> But, as things stand, you need enough of the JDK to run a Java > >compiler > >> and build the OpenJDK class libraries. GCJ currently fulfils that > >need > >> where there isn't already an OpenJDK installation available. > >> -- > > > >Actually, this makes me think... > > > >IcedTea already depends on CACAO and JamVM for alternate builds of > >OpenJDK. We could instead include the bytecode binaries for GNU > >Classpath > >in IcedTea, bootstrap JamVM and use that to bootstrap OpenJDK. That > >would remove our dependency on gcj and make IcedTea largely > >self-sufficient. > >It would also mean we could drop a bunch of conditional code which > >depends > >on what the system bootstrap JDK is, because it would always be the > >in-tree > >solution. > > > >We'd still need more than six months to make this transition though, > >as such a change really needs time for testing. > > OK, so how about deprecating Java for GCC 6 by removing it from the default > languages and removing it for GCC 7 or before we switch to git (whatever > happens earlier?) > Yeah, that's what I suggested at the end of [0] so +1 from me. As Joseph says, I don't think the move to git is relevant to this. If it had happened sooner, though, I'd have properly merged GNU Classpath more frequently... ;) > Richard. > > > [0] https://gcc.gnu.org/ml/java-patches/2015-q3/msg00029.html -- 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
Re: [PATCH, libjava/classpath]: Fix overriding recipe for target 'gjdoc' build warning
- Original Message - > On 08/20/2015 10:03 AM, Andrew Hughes wrote: > > - Original Message - > >> On 08/20/2015 09:27 AM, Andrew Haley wrote: > >>> 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. > >> Right. So the question is there some reason why OpenJDK can't be used > >> to bootstrap itself? Ie, is there a fundamental reason why Andrew needs > >> to drop back down to GCJ and start the bootstrapping process from scratch. > >> > >> ISTM that ideally the previous version of OpenJDK would be used to > >> bootstrap the new version of OpenJDK. > >> > >> Which leaves the question of how to deal with new platforms, but it > >> sounds like there's a cross-compilation process starting with OpenJDK 8 > >> which ought to solve that problem. > >> > > > > The issue is that we're still supporting a version of OpenJDK/IcedTea where > > there is no previous version (6). Once that goes, gcj could go too. This > > is still just a little too soon. > But surely OpenJDK6 can build OpenJDK6, right? I don't see you're > fundamentally getting anything from always starting with a GCJ bootstrap. > I'm talking about when you don't already have OpenJDK 6. > > > > That's where it comes unstuck. How do you get a JDK built when there are > > no JDK binaries for your architecture? > Cross compilation, just like folks do for Ada. > Which still needs a JDK somewhere and, as Matthias mentioned, the build system on older versions of OpenJDK (the ones were talking about) doesn't really support cross-compilation. I had to hack around just to get x86 on x86_64 to work. > > >> > > > > I'm not against this long-term, just not immediately. Deprecating it now > > and removing it in the next release cycle (7?) would probably be enough, > > but we need a little more time to wind down dependencies. I don't see us > > needing it in a GCC released in 2017. > I was of the opinion that we should remove it from the default languages > to be built. Others wanted to be more aggressive :-) I actually thought that change would have happened a long long time ago ;) I'm actually for the aggressive approach, just on a longer time scale, as I'll need time to transition IcedTea away from gcj. > > jeff > -- 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
Re: [PATCH, libjava/classpath]: Fix overriding recipe for target 'gjdoc' build warning
- Original Message - > snip... > > > > Having classpath (with binary files!) In the GCC SVN (or future git) > > repository is a significant burden, not to mention the size of the > > distributed source tarball. > > > > If we can get rid of that that would be a great step in reducing the > > burden. > > > > Iff we can even without classpath build enough of java to be useful (do you > > really need gcj or only gij for bootstrapping openjdk? After all ecj is > > just > > a drop-in to gcc as well). > > All the Java compilers are written in Java (ecj & javac). So to run them, you > need a JVM and its class library. > > It's those binary files which allow gcj to bootstrap the stack. If OpenJDK > had a minimal binary class library, it would be able to bootstrap itself. > > But, as things stand, you need enough of the JDK to run a Java compiler > and build the OpenJDK class libraries. GCJ currently fulfils that need > where there isn't already an OpenJDK installation available. > -- Actually, this makes me think... IcedTea already depends on CACAO and JamVM for alternate builds of OpenJDK. We could instead include the bytecode binaries for GNU Classpath in IcedTea, bootstrap JamVM and use that to bootstrap OpenJDK. That would remove our dependency on gcj and make IcedTea largely self-sufficient. It would also mean we could drop a bunch of conditional code which depends on what the system bootstrap JDK is, because it would always be the in-tree solution. We'd still need more than six months to make this transition though, as such a change really needs time for testing. -- 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
Re: [PATCH, libjava/classpath]: Fix overriding recipe for target 'gjdoc' build warning
snip... > > Having classpath (with binary files!) In the GCC SVN (or future git) > repository is a significant burden, not to mention the size of the > distributed source tarball. > > If we can get rid of that that would be a great step in reducing the burden. > > Iff we can even without classpath build enough of java to be useful (do you > really need gcj or only gij for bootstrapping openjdk? After all ecj is just > a drop-in to gcc as well). All the Java compilers are written in Java (ecj & javac). So to run them, you need a JVM and its class library. It's those binary files which allow gcj to bootstrap the stack. If OpenJDK had a minimal binary class library, it would be able to bootstrap itself. But, as things stand, you need enough of the JDK to run a Java compiler and build the OpenJDK class libraries. GCJ currently fulfils that need where there isn't already an OpenJDK installation available. -- 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
Re: [PATCH, libjava/classpath]: Fix overriding recipe for target 'gjdoc' build warning
- Original Message - > On 08/20/2015 05:03 PM, Andrew Hughes wrote: > > The issue is that we're still supporting a version of OpenJDK/IcedTea where > > there is no previous version (6). > > Surely OpenJDK 6 can build itself. And in the unlikely event of an > entirely new architecture which has No OpenJDK we'd have to grab an > old GCJ and build it with that. > > If GCJ is included as part of GCC but is not maintained and tested, it > will soon rot. That isn't an option IMO. > > Andrew. > I agree and I'm not saying keep it forever. Just give us a little time to adapt to its removal by obsoleting now and removing it in the next release cycle, rather than deleting it now six months before a release. It's not just "entirely new architecture"s that have no OpenJDK, but any system which, for whatever reason, doesn't have a binary available. GCC follows this process of obsolescence then removal for ports (e.g. [0]). I don't see why a language port should be any different. [0] https://gcc.gnu.org/gcc-4.9/changes.html -- 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
Re: [PATCH, libjava/classpath]: Fix overriding recipe for target 'gjdoc' build warning
- Original Message - > On 08/20/2015 09:27 AM, Andrew Haley wrote: > > 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. > Right. So the question is there some reason why OpenJDK can't be used > to bootstrap itself? Ie, is there a fundamental reason why Andrew needs > to drop back down to GCJ and start the bootstrapping process from scratch. > > ISTM that ideally the previous version of OpenJDK would be used to > bootstrap the new version of OpenJDK. > > Which leaves the question of how to deal with new platforms, but it > sounds like there's a cross-compilation process starting with OpenJDK 8 > which ought to solve that problem. > The issue is that we're still supporting a version of OpenJDK/IcedTea where there is no previous version (6). Once that goes, gcj could go too. This is still just a little too soon. > > > > >> 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. > And how much value is there in that in the real world? > I do know it's been used recently on Gentoo to bootstrap IcedTea on non-x86 archs. That's where it comes unstuck. How do you get a JDK built when there are no JDK binaries for your architecture? > > > > 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. > Right. I think we last discuss this in 2013 and there was still some > benefit in keeping GCJ building, but that benefit is dwindling over time. > > > There's an ongoing cost to every GCC developer to keep GCJ functional as > changes in the core compiler happen. Furthermore, there's a round-trip > cost for every patch under development by every developer in the > boostrap & testing cycles. > > Given the marginal benefit to GCC and OpenJDK and the fairly high cost, > we'd really prefer to drop GCJ. > I'm not against this long-term, just not immediately. Deprecating it now and removing it in the next release cycle (7?) would probably be enough, but we need a little more time to wind down dependencies. I don't see us needing it in a GCC released in 2017. > > Jeff > > -- 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
Re: [PATCH, libjava/classpath]: Fix overriding recipe for target 'gjdoc' build warning
- 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
Re: [PATCH, libjava/classpath]: Fix overriding recipe for target 'gjdoc' build warning
- Original Message - > 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 > Andrew Haley doesn't do releases of IcedTea 1.x and 2.x every three months. I do. > Tom > -- 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
Re: [PATCH, libjava/classpath]: Fix overriding recipe for target 'gjdoc' build warning
- 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. >From a personal point of view, I need gcj to make sure each new IcedTea 1.x >and 2.x release bootstraps. 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? > 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
Re: [PATCH, libjava/classpath]: Fix overriding recipe for target 'gjdoc' build warning
- Original Message - > On Fri, Aug 7, 2015 at 1:21 PM, Uros Bizjak wrote: > > > Attached patch fixes: > > > > Makefile:871: warning: overriding recipe for target 'gjdoc' > > Makefile:786: warning: ignoring old recipe for target 'gjdoc' > > > > build warning when compiling libjava. > > > > The problem was in configure.ac: we have to depend gjdoc build on > > CREATE_WRAPPERS in the same way as other tools are dependent a couple > > of lines above. > > > > While in this area, I also removed obsolete automake < 1.11 > > workaround. As mentioned in HACKING: "Make sure you have Automake > > 1.11.1 installed. Exactly that version!" > > > > I have included all generated files in the diff. The changes are small > > and they illustrate the effect of the patch. > > > > 2015-08-07 Uros Bizjak > > > > * configure.ac (tools/gjdoc): Depend on CREATE_WRAPPERS. > > * configure: Regenerate. > > * tools/Makefile.am: Remove unneeded dependencies for Automake 1.11. > > * tools/Makefile.in: Regenerate. > > > > Patch was bootstrapped on x86_64-linux-gnu, Fedora 22. > > > > OK for GCC mainline? > > I have committed this patch to GCC mainline SVN repository. Both > issues can be considered obvious and the fix is trivial. > > Also, it looks like the official classpath repository is a dead place > for a couple of years. > Hardly. http://git.savannah.gnu.org/cgit/classpath.git/log/ I've taken the liberty of applying your patch to keep GCJ in sync with its upstream. > Uros. > -- 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
Re: [PATCH, libjava/classpath]: Fix overriding recipe for target 'gjdoc' build warning
- Original Message - > Jeff> It's probably time for the occasional discussion WRT dropping > Jeff> gcj/libjava from the default languages and replace them with either > Jeff> Ada or Go. > > It's long past time to remove it. It's only had minimal maintenance for > years now. No one is writing new features for it or fixing bugs. There > aren't any significant users. > > I've always felt I should be the one to pull the trigger. If this is > acceptable I can take a stab at preparing a patch. > > I thought maybe this would also enable deleting boehm-gc, zlib, or > libffi; but I see now they all have other users in the tree now. > > Tom > No, it isn't. It's still a necessity for initial bootstrapping of OpenJDK/IcedTea. By all means, disable it as a default but don't remove it. -- 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
Re: [patch] [java] bump libgcj soname
- Original Message - > On Tue, Apr 21, 2015 at 01:04:04PM -0400, Andrew Hughes wrote: > > - Original Message - > > > On Tue, Apr 21, 2015 at 04:07:13PM +0200, Matthias Klose wrote: > > > > bump the libgcj soname on the trunk, as done for every release cycle, > > > > > > Is that really needed though these days? > > > Weren't there basically zero changes to libjava (both libjava and > > > libjava/classpath) in the last 2 or more years? > > > The few ones were mostly updating Copyright notices, minor configure > > > changes, but I really haven't seen anything ABI changing for quite a > > > while. > > > > > > > On the Classpath side, there's a bunch of stuff to merge in that would > > change the ABI. It's a matter of finding a good point at which to do it > > and time to do so. I keep missing the right point in the gcc lifecycle. > > Now might be a good time (any time next 6.5 months or so), and if that is > done, surely I have no issue with bumping the soname. > Ok, that should be possible. > Jakub > -- Andrew :) 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
Re: [patch] [java] bump libgcj soname
- Original Message - > On Tue, Apr 21, 2015 at 04:07:13PM +0200, Matthias Klose wrote: > > bump the libgcj soname on the trunk, as done for every release cycle, > > Is that really needed though these days? > Weren't there basically zero changes to libjava (both libjava and > libjava/classpath) in the last 2 or more years? > The few ones were mostly updating Copyright notices, minor configure > changes, but I really haven't seen anything ABI changing for quite a while. > On the Classpath side, there's a bunch of stuff to merge in that would change the ABI. It's a matter of finding a good point at which to do it and time to do so. I keep missing the right point in the gcc lifecycle. > Jakub > -- Andrew :) 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
Re: Remove obsolete Solaris 9 support
- Original Message - > On Sat, 2014-04-19 at 09:03 +0100, Andrew Haley wrote: > > On 04/16/2014 12:16 PM, Rainer Orth wrote: > > > * I'm removing the check from classpath. Again, I'm > > > uncertain if this is desirable. In the past, classpath changes were > > > merged upstream by one of the libjava maintainers. > > > > We should not diverge from GNU Classpath unless there is a strong reason > > to do so. > > I think the configure check is mostly harmless, but wouldn't be opposed > removing it. It really seems to have been added explicitly for Solaris > 9, which is probably really dead by now. Andrew Hughes, you added it > back in 2008. Are you still using/building on any Solaris 9 setups? > I vaguely remember adding it. I was building on the university's Solaris 9 machines at the time. They've long since replaced them with GNU/Linux machines and I've been at Red Hat for over five years, so those days are long gone :) I have some Freetype fixes to push to Classpath as well, so I'll fix this too and look at merging to gcj in the not-too-distant future. I think it's long overdue. Ideally, the change should be left out of this patch, so as to avoid conflicts. > Cheers, > > Mark > > Thanks, -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07
Re: [wwwdocs,Java] comparison of libgcj with Kaffe link is gone
- Original Message - > The regular comparison with Kaffe is gone after the restructuring/ > move to github, and I could not find any replacement URL. > > I applied this patch. If any of you has a new URL, we can resurrect. > > Gerald > > 2012-11-01 Gerald Pfeifer > > * status.html: Remove comparison with Kaffe. > > Index: status.html > === > RCS file: /cvs/gcc/wwwdocs/htdocs/java/status.html,v > retrieving revision 1.31 > diff -u -3 -p -r1.31 status.html > --- status.html 1 Nov 2011 14:07:02 - 1.31 > +++ status.html 1 Nov 2012 22:16:48 - > @@ -39,11 +39,6 @@ you should not (yet) rely on their corre > > Implemented Packages > > -You can also see http://www.kaffe.org/~stuart/japi/";>a > -comparison of libgcj with the JDK. This is updated nightly. It > -is run against the cvs trunk, and includes GNU Crypto in its > analysis. > -This is the most up-to-date analysis of API differences. > - > > java.applet > Believed to be complete, but note that without a functional AWT > I'd have to look at the context of this, but (assuming I can actually get my webserver to stay up reliably) I have more up-to-date comparisons on there, comparing OpenJDK with GNU Classpath. GCJ could easily be added and listed in the docs. -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07
Re: [wwwdocs,Java] Replace sources.redhat.com by sourceware.org
- Original Message - > ...and some other simplifications and improvements I noticed on > the way. > > This was triggered by a note that the sources.redhat.com DNS entry > is going to go away at some point in the future that I got yesterday. > > Applied. > > Gerald > > > 2012-10-21 Gerald Pfeifer > > * news.html: Replace references to sources.redhat.com by > sourceware.org. > Avoid a reference to CVS. > Some style adjustments to the February 8, 2001 entry. > > Index: news.html > === > RCS file: /cvs/gcc/wwwdocs/htdocs/java/news.html,v > retrieving revision 1.12 > diff -u -3 -p -r1.12 news.html > --- news.html 19 Sep 2010 20:35:03 - 1.12 > +++ news.html 21 Oct 2012 02:02:51 - > @@ -153,7 +153,7 @@ code size heuristics. It is enabled by > > Gary Benson from Red Hat has released > http://people.redhat.com/gbenson/naoko/";>Naoko: a > subset > -of the http://sources.redhat.com/rhug/";>rhug packages > +of the http://sourceware.org/rhug/";>rhug packages > that have been repackaged for eventual inclusion in Red Hat Linux. > Naoko basically comprises binary RPMS of Ant, Tomcat, and their > dependencies built with gcj. > @@ -172,8 +172,8 @@ A team of hackers from Red Hat has relea > of http://www.eclipse.org/";>Eclipse, a free software > IDE > written in Java, that has been compiled with a modified gcj. > You can find more information > -http://sources.redhat.com/eclipse/";>here. We'll be > -integrating the required gcj patches into cvs in the near future. > +http://sourceware.org/eclipse/";>here. We'll be > +integrating the required gcj patches in the near future. > > > July 31, 2003 > @@ -426,7 +426,7 @@ find bugs! > February 8, 2001 > > Made use of Warren Levy's change to the > -http://sources.redhat.com/mauve/";>Mauve test suite to > handle > +http://sourceware.org/mauve/";>Mauve test suite to > handle > regressions. > Modifications have been made to mauve.exp to copy the newly > created > xfails file of known library failures from the source tree > @@ -434,9 +434,9 @@ to the directory where the libjava ' > This allows the testsuite to ignore XFAILs and thus > highlight > true regressions in the library. The Mauve tests are > automatically run as part of a libjava > -'make check' as long as the Mauve suite is accessible > -and the env var MAUVEDIR is set to point to the top-level > -of the http://sources.redhat.com/mauve/download.html";>Mauve > source. > +make check as long as the Mauve suite is accessible and > the > +environment variable MAUVEDIR is set to point to the > top-level > +of the Mauve sources. > > > January 28, 2001 > It's never been obvious to me how the web material gets updated. GCJ regularly misses out on being mentioned in changes too, despite fixes going in. -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07
Re: [PATCH, libjava] Use accessor functions to manipulate xmlOutputBuffer
- Original Message - > Andrew Hughes writes: > > > Don't worry about reverting it. I'll add it to Classpath now, then > > they'll be in sync when we do the next merge. > > Thank you. > Done: http://git.savannah.gnu.org/cgit/classpath.git/commit/?id=4d4db712cf4df4feb4d7b98bb1b5b448218500b3 > > In future, please post changes to files under the libjava/classpath > > directory to > > classp...@gnu.org and feel free to ping me directly if you don't > > get a response in a reasonable timeframe. It just makes my life a > > bit > > easier when it comes to doing the merges :-) > > OK, I will do. Sorry for the inconvenience. No worries. It's not immediately obvious for someone new to the libjava codebase. > > -- > Dodji > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07
Re: [PATCH, libjava] Use accessor functions to manipulate xmlOutputBuffer
- Original Message - > Andrew Hughes writes: > > >> OK. > >> > > > > As this is a GNU Classpath change, it should go in there first to > > avoid creating > > a divergence which will cause later problems in merging. Classpath > > is regularly > > merged into gcj as a whole. > > > > I found several patches during the last merge which had only been > > added to gcj > > (some without ChangeLog entries) and this slowed the process down > > considerably. > > > > Dodji, I can push this to Classpath on your behalf if you don't > > have commit > > access. > > Oops. I committed the patch before I saw your message. Sorry. > > If you agree, I can revert the commit so that you can commit it to > classpath then. I don't think I have commit access to GNU classpath. > > Sorry for the inconvenience. > Don't worry about reverting it. I'll add it to Classpath now, then they'll be in sync when we do the next merge. In future, please post changes to files under the libjava/classpath directory to classp...@gnu.org and feel free to ping me directly if you don't get a response in a reasonable timeframe. It just makes my life a bit easier when it comes to doing the merges :-) > -- > Dodji > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07
