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

[Stuart Marks]

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