This is the mail archive of the java-patches@gcc.gnu.org mailing list for the Java project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On 08/20/2015 09:27 AM, Andrew Haley wrote:
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.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.htmlif 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.
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.
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?
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.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.
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.
Jeff
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |