RFR: 8016780: (xs) README-builds.html misses crucial requirement on bootstrap JDK

[Daniel Fuchs]

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
>>