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

[Jonathan Gibbons]

On 12/13/17 10:36 AM, joe darcy wrote:
> 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

There's also

3a) Update build of the INTERIM components (used for bootstrapping the 
build) to use latest GA release

Somewhat related, as a one-off,   JDK 9 javac added a class called 
JDK9Wrappers to provide reflective access to new-in-JDK-9 API. These 
wrappers can now be removed, and the API used directly.

-- Jon