JDK 12 RFR of JDK-8205615: Start of release updates for JDK 12 / JDK-8205621: Increment JDK version for JDK 12

[David Holmes]

Hi Joe,

Okay - no problem. Just looking for opportunities to streamline the process.

Cheers,
David

On 26/06/2018 9:42 AM, joe darcy wrote:
> Hi David,
> 
> 
> On 6/25/2018 4:13 PM, David Holmes wrote:
>> Hi Joe,
>>
>> On 26/06/2018 4:10 AM, joe darcy wrote:
>>> Hello,
>>>
>>> With the JDK 11 and 12 split fast approaching [1], it is time to work 
>>> on the various start of release update tasks for JDK 12. Those tasks 
>>> are being tracked under the umbrella bug JDK-8205615: "Start of 
>>> release updates for JDK 12".
>>>
>>> This thread is to review the build-related portions of the work 
>>> including JDK-8205621: "Increment JDK version for JDK 12." Current 
>>> webrev:
>>>
>>>      http://cr.openjdk.java.net/~darcy/8205615.4/
>>
>> make/autoconf/version-numbers
>>
>> If we're going to ensure we bump the version and classfile version 
>> together then we should be able to restore:
>>
>> DEFAULT_VERSION_CLASSFILE_MAJOR=56  # "`$EXPR $DEFAULT_VERSION_FEATURE 
>> + 44`"
>>
>> to just:
>>
>> DEFAULT_VERSION_CLASSFILE_MAJOR="`$EXPR $DEFAULT_VERSION_FEATURE + 44`"
> 
> Hmm. I don't know if I want to implicitly mandate we bump the class file 
> version and JDK version at the same time.
> 
>>
>> Possibly we could also set:
>>
>> DEFAULT_ACCEPTABLE_BOOT_VERSIONS
>>
>> to use DEFAULT_VERSION_FEATURE, DEFAULT_VERSION_FEATURE-1 
>> DEFAULT_VERSION_FEATURE-2 ? If that is our boot JDK policy. Or will we 
>> drop 10 at some point in the process?
> 
> We will drop 10 at some point. Per the last round of conversations, the 
> boot JDK policy is official builds are done with the most recently GA'ed 
> release, which right now is 10, but we want to allow the subsequent 
> releases too for bootstrap builds, etc.
> 
>>
>> ---
>>
>> make/common/SetupJavaCompilers.gmk
>>
>> Again if we're bumping everything en-masse can we use 
>> DEFAULT_VERSION_FEATURE instead of hard-wiring 12?
> 
> Same reaction; I think it is acceptable if we explicitly opt-into the 
> new source/target values for the build.
> 
> If we end up successfully doing the coordinated update for 12 followed 
> by the same feat for 13, I'd be more inclined to change these files to 
> avoid needing to do explicit updates ;-)
> 
>>
>> And should these be using --release instead of -source + -target?
> 
> That is a reasonable suggestion and I inquired about that myself with 
> Erik off-list. There may have been a hiccup using that in the past and 
> it is worth looking into again. However, I'd prefer to handle that 
> investigation separately to avoid delaying the start-of-12 changes from 
> getting back.
> 
> Thanks,
> 
> -Joe
> 
>>
>> ---
>>
>> Thanks,
>> David
>>
>>> A handful of test failures still need to be addressed, so there will 
>>> be some minor adjustments to the aggregate set of changes before they 
>>> are pushed.
>>>
>>> Cheers,
>>>
>>> -Joe
>>>
>>> [1] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-June/001462.html
>>>
>