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

[joe darcy]

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