Hi folks,
Looks like I generated a bit of discussion here. Let's try to tease apart some
of the issues.
1) I think we need a better articulation of the rule about the boot JDK being
N-1, thus my proposed change to the README. I don't mean to ever prohibit
anybody from ever trying to build JDK N with a boot JDK N, but that should be a
special case. If the wording I proposed isn't satisfactory, please suggest
alternatives.
2) Boot cycle build. Yes, after building JDK N, we must support a boot cycle
build where the just-built JDK N is used as the boot JDK to build itself again.
This is really a special case within the build system, however. At configure
time, the boot JDK always should be N-1, and when the build gets to the boot
cycle phase, it either knows or can be taught to treat this phase differently
from the first phase.
3) Rules enforcement / mistake avoidance. I think it makes the most sense for
configure to ensure that the configured boot JDK is N-1. (Naturally the
configured boot JDK will be overridden during the boot cycle phase. It could
also be overridden by specifying an additional option explicitly.) The main
point here is to avoid mistakes, so that someone who happens to have a JDK 8 in
their path doesn't accidentally have it picked up by configure.
Unfortunately the -source 7 -target 7 approach is insufficient, because while
it rolls back the language level and classfile version, it does *not* roll back
the API version. To get the old API version, one has to construct a
bootclasspath with the old class libraries, and at that point one might as well
just use the N-1 JDK.
#include <lecture_from_joe_darcy_with_link_to_his_blogpost_on_this_topic>
4) Could jaxp, jaxws, and corba be built with the current JDK, not the boot
JDK? Sure, probably. I spoke with Jon G on this topic the other day and we
didn't come up with any really good reasons why they need to be built with the
boot JDK. Historically they were upstream repositories so they were usually
based on a backrev JDK anyway, so there was no real need for them to use the
latest features. Also, using the boot JDK was probably an incidental outcome of
the way the old build system was put together. (Old-timers lurking -- or not
:-) -- on this list will certainly know better than me.) The new build system
does the same, since one of its requirements is that it slavishly match the
output of the old build system.
In principle I don't see any reason why these libraries couldn't be built with
the current JDK instead of the boot JDK. This might be a fairly large
restructuring of the build system, though.
Of course, langtools still needs to be built with the JDK N-1 boot JDK. I'm not
sure about the Java files in hotspot. Can someone enlighten us?
--
If people think it's a good idea I could file RFEs for #3 and #4.
I would like people to review the README change as well. Thanks.
s'marks
On 6/17/13 11:57 PM, Daniel Fuchs wrote:
On 6/18/13 8:28 AM, David Holmes wrote:
On 18/06/2013 4:02 PM, Jonathan Gibbons wrote:
The only problem with using N is that you don't know whether you have
broken building with N-1. Therefore the general recommendation for most
people should be to always use N-1. I think Stuart is just searching
for ways to make people aware that using N-1 is "the right thing to do".
There was certainly an issue here that caused a problem because the code used
a JDK8 API that was not available when the source was compiled with JDK7. And
sure compiling with 7u boot JDK would have caught that.
But we have lots of code that only compiles with JDK8 and that is the way we
want it, else JDK8 could not take advantage of any new language features or
APIs in JDK8. The real problem here was that the code in question is code
that is not built in a way that allows it to use the latest language features
or APIs. In which case perhaps the real fix is to use build commands that
enforce this restriction ie by using -source 7 -target 7 ?
David
Hi David,
In the case of Jaxp - I'm not sure why exactly is Jaxp compiled with the boot
JDK.
It comes early in the build cycle - at a time when the N JDK hasn't been
compiled yet.
But is this a mere convenience - or is there a good technical reason for this?
Because personally - I would love to be able to use JDK N feature in the JAXP
source
code.
One could argue that using N features impairs the ability to port the fixes to
N-1, but
this is already the case today anyway: for many of the fixes I ported from 8 to
7 I had to
modify my patches because I was using N-1 features in N, and therefore had to
convert
the code to only use N-2 features when porting from N to N-1.
So if that is possible (and it may not be - I'm not a build expert) - I would
argue to
remove the restriction for Jaxp - rather than enforce it.
best regards,
-- daniel
-- Jon
On 06/17/2013 10:04 PM, David Holmes wrote:
I thought the only rule was "must be buildable by N-1", not that you
must not try to use N!
Can the problem preventing a build using JDK8 as the boot JDK not be
corrected? I'm assuming it is one of the more unusual parts of the
build where we mess with bootclasspath etc?
David
On 18/06/2013 10:21 AM, Stuart Marks wrote:
On 6/17/13 4:02 PM, Kelly O'Hair wrote:
Rule #1 Nobody reads the README
Rule #2 When things go wrong, blame the README
I of course have no objection to the change, however, I'm not
convinced it will
help much the next time someone runs into this. :^(
Hi Kelly! You still read this stuff here? :-)
Yeah, I have no illusions that changing the README will prevent many, if
any, future occurrences of this problem. However, we had an internal
discussion on this incident where the N-1 rule was asserted. There was
no dispute about the rule, but I went off to find where it was
documented, and found only the fairly weak statement in the README. So,
at the very least, that ought to be fixed.
A stronger step would be to modify configure to check the version of the
boot JDK and to complain if it doesn't match N-1. Or perhaps even N-1
and update >= 7. What do you think? I was considering filing an RFE.
A restriction in configure would probably be more effective at
preventing these kinds of errors.
s'marks
