RFR: JDK-8200083: Bump bootjdk requirement for JDK 11 to JDK 10

[Magnus Ihse Bursie]

On 2018-03-22 16:13, Jonathan Gibbons wrote:
> Magnus,
>
> There has always been a desire that most of JDK is free to use the 
> latest language and API features, meaning we must use the latest javac 
> to compile most most of JDK.   That is where the "interim javac" comes 
> in.
>
> The interim JDK relies on javac and related tools being compilable by 
> the boot JDK.  This imposes a restriction that the source code of 
> those tools must be conformant to the source version supported by the 
> boot JDK, meaning no use of any newer features. The javac team have 
> always lived with and accepted the N-1 restriction that this imposes. 
> With a more rapid cadence, it might be appropriate to revisit the N-1 
> rule. But since a "last LTS" rule may imply N-5 or N-6 or so, that 
> seems like too much.
>
> I note that this is not just an issue for javac source code.  If we 
> were currently on a "last LTS" rule, that implies JDK 8, which means 
> the build would still have to be bimodal and support both 
> (boot)classpath and modular builds. OK, that window is closing, but 
> the general point is that supporting older versions may affect more 
> than just the javac team.

I would not propose a "last LTS" scheme, that seems far to infrequent to 
be reasonable. But maybe "N-2" might be an acceptable compromise?

Just to be clear: As far as I understand, the balance to strike here is 
between:
1) on one hand, giving developers more time to adjust their build system 
to a newly available boot JDK.
2) on the other hand, allowing developers of javac access to new JDK 
features.

In keeping with the N-1 rule, we are nominally doing the same thing, but 
practically shifting things towards 2). That might still be the right 
thing to do, but we will then need to acknowledge that this is what 
we're doing.

Personally, I don't have any strong opinion either way. I agree with 
Erik's idea to keep the test matrix minimal, but on the other hand, 
there's a huge number of possible configurations to build OpenJDK on 
which is not regularly tested by Oracle's build system, and that works 
fine in most cases. If someone from the community needs it and it is 
broken, they can submit a patch. I could live with stating that "N-1" is 
officially supported and is guaranteed to work, but we will also support 
"N-2" but you'll have to test it yourself and submit bug fixes if it 
does not work.

But if javac developers are seriously hindered in their effort to 
enhance Java due to this, then maybe developer convenience is not as 
important.

/Magnus


>
> -- Jon
>
>
> On 3/21/18 11:10 PM, Magnus Ihse Bursie wrote:
>> Jon,
>>
>>> 21 mars 2018 kl. 23:20 skrev Jonathan Gibbons 
>>> <jonathan.gibbons at oracle.com>:
>>>
>>> Holding javac and related tools back to the latest LTS would indeed 
>>> be somewhat onerous.
>> Can we use the interim JDK build to get around this? Something like, 
>> if we can build a interim JDK with somewhat older tools, it can then 
>> be used to compile the javac proper?
>>
>> I can see that how with the increased release cadence, the 
>> assumptions behind the old N-1 scheme might not be valid anymore.
>>
>> /Magnus
>>
>>> -- Jon
>>>
>>>> On 03/21/2018 03:07 PM, Martin Buchholz wrote:
>>>> Now that we are releasing jdks an order of magnitude faster than 
>>>> before, we
>>>> should reconsider the N-1 boot jdk policy.
>>>>
>>>> The primary beneficiaries of this are compiler-dev, who might like 
>>>> to code
>>>> using the very features they are implementing.
>>>>
>>>> But for users, being able to bootstrap with an ancient jdk is 
>>>> definitely
>>>> convenient.
>>>>
>>>> A good compromise might be to be able to bootstrap with the most 
>>>> recent LTS
>>>> release (jdk 8) but it might already be too late for that.
>>>>
>>>> On Wed, Mar 21, 2018 at 2:51 PM, Erik Joelsson 
>>>> <erik.joelsson at oracle.com>
>>>> wrote:
>>>>
>>>>> Now that JDK 10 has been officially released we can update the 
>>>>> boot jdk
>>>>> requirement for JDK 11. Cross posting this to jdk-dev to raise 
>>>>> awareness of
>>>>> this rather disruptive change.
>>>>>
>>>>> This patch changes the requirement on boot jdk version in 
>>>>> configure (and
>>>>> updates the configuration that controls what JDK to use as boot in 
>>>>> Oracle's
>>>>> internal build system).
>>>>>
>>>>> Webrev: http://cr.openjdk.java.net/~erikj/8200083/webrev.01/
>>>>>
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8200083
>>>>>
>>>>> /Erik
>>>>>
>>>>>
>