Initial JDK 11 RFR of JDK-8173382: Add -source 11 and -target 11 to javac - Java Bug System & JDK-8193291: Add SourceVersion.RELEASE_11

[joe darcy]

Hi David,


On 12/12/2017 8:56 PM, David Holmes wrote:
> Hi Joe,
>
> On 13/12/2017 9:20 AM, joe darcy wrote:
>> Hi David,
>>
>>
>> On 12/12/2017 1:32 PM, David Holmes wrote:
>>>

[snip]

>>>
>>
>> For background, what we've done in the past is at the very start of a 
>> new JDK release, first create -source/-target ${N+1} that begin as 
>> aliases for ${N} and are the default -source/-target for javac. [1] 
>> As new language features are developed, the javac implementation adds 
>> allowFeatureFoo() predicates which turn into
>>
>>      return sourceOptionBeingUsed >= firstSourceWhichAllowsFeature
>>
>> So the operational distinction between -source ${N} and -source 
>> ${N+1} comes about after language changes have been made for release 
>> ${N+1}. For -target, since there is often not a hard dependency 
>> between new Java language features and JVM features, an operational 
>> distinction between successive values of -target, and thus successive 
>> class file versions, can come about later in the release. For 
>> example, in JDK 10 the language feature var/local variable type 
>> inference enabled by -source 10 was in JDK 10 builds a few months 
>> before -target 10 mapped to an updated class file version.
>>
>> We could follow the same path for the JDK 10 -> 11 transition. Paul 
>> has suggested also updating the class file version at the same time 
>> this time around.
>
> I'm a little unclear as to the distinction between allowing for 
> -source/-target 11 and switching them to be the default. Especially if 
> you incorporate the classfile version change then we would have a JDK 
> reporting itself as JDK 10 but which uses -source/-target 11 and 
> produces version 55 classfiles. I would have thought it a two step 
> process:
> - prepare for new defaults
> - switch to new defaults (in conjunction with version change)
>
> Anyway, none of the proposed changes have any impact on hotspot 
> AFAICT. It is only when the actual version is updated to 11 that 
> hotspot, and other entities will have to be updated. I'm still unclear 
> if someone is actually driving the entire "update to version 11" 
> process? Is there an umbrella issue for it?
>

There are various changes associated with a JDK N to (N+1) update 
including (but not limited to):

     1) New -source/-target value in javac
     2) Make new -source/-target value the default in javac
     3) Change build of the JDK to use new -source/-target
     4) Increment version
     5) Support new --release value in javac
     6) Output new class file format
     7) Have HotSpot accept new class file format
     ...

For the last few releases, we've done 1) through 4) in b01 of the new 
release, although typically via multiple changesets since 4) has been 
done separately from 1) through 3) and 3) had to be done separately from 
1) and 2) since different repos were affected before the repo consolidation.

It is desirable but not strictly necessary to bundle this set of updates 
into as few changesets as possible. In particular, I think it is 
acceptable if the master repo has source code states before the first 
promoted build where not all of 1) through 4) are fixed.

Cheers,

-Joe