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]

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


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.



 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?


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.


Jeff


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]