RFR: 8016780: (xs) README-builds.html misses crucial requirement on bootstrap JDK
stuart.marks at oracle.com
Tue Jun 18 07:42:20 UTC 2013
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
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.
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.
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 ?
> 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
> 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
> 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?
>>>> 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.
More information about the build-dev