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

[David Holmes]

Hi Stuart,

 > I would like people to review the README change as well. Thanks.

I don't think we should simply say

"Do not use a build of JDK 8 as the boot JDK for building JDK 8."

as that doesn't explain what the issue is. If I'm building the JDK for 
my own use I can use JDK8. So how about:

"JDK 8 developers should not use JDK 8 as the boot JDK, to ensure that 
code changes are compatible with building using JDK 7."

?

David

On 18/06/2013 5:42 PM, Stuart Marks wrote:
> 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
>>>>
>>