RFR: 8016780: (xs) README-builds.html misses crucial requirement on bootstrap JDK
daniel.fuchs at oracle.com
Tue Jun 18 06:57:03 UTC 2013
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 ?
In the case of Jaxp - I'm not sure why exactly is Jaxp compiled with the
It comes early in the build cycle - at a time when the N JDK hasn't been
But is this a mere convenience - or is there a good technical reason for
Because personally - I would love to be able to use JDK N feature in the
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.
>> -- 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.
>>>> 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