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

Tue Jun 18 09:16:00 UTC 2013

On 06/18/2013 10:02 AM, David Holmes wrote:
> 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."

This suggested wording, along with Stuarts other additions to the 
README, look fine. I think this should be pushed, and the other issues 
handled separately.

-Chris.

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