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

joe darcy joe.darcy at oracle.com
Fri Mar 23 16:58:27 UTC 2018


In addition, the APIs in the java.compiler module are bootstrapped along 
with javac. Therefore, these APIs also have to abide by the same (N-k)  
language feature policy as javac. If the bootstrap is older than 
necessary, maintenance of these APIs would be overly constrained.

-Joe


On 3/23/2018 9:07 AM, Magnus Ihse Bursie wrote:
> 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
>>>>>>
>>>>>>
>>
>



More information about the jdk-dev mailing list