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

David Holmes david.holmes at
Wed Dec 13 04:56:29 UTC 2017

Hi Joe,

On 13/12/2017 9:20 AM, joe darcy wrote:
> Hi David,
> On 12/12/2017 1:32 PM, David Holmes wrote:
>> Hi Joe,
>> On 13/12/2017 7:27 AM, joe darcy wrote:
>>> Hi David,
>>> On 12/12/2017 1:11 PM, David Holmes wrote:
>>>> Hi Joe,
>>>> On 12/12/2017 5:04 PM, joe darcy wrote:
>>>>> Hello,
>>>>> With the JDK 11 line of development opening up in a few days, a few 
>>>>> changes are needed to prepared to turn a JDK 10 code base into a 
>>>>> JDK 11 one including:
>>>>>      JDK-8173382: Add -source 11 and -target 11 to javac
>>>>>      JDK-8193291: Add SourceVersion.RELEASE_11
>>>>>      Webev:
>>>>>      CSRs:
>>>>>          JDK-8193350: Add -source 11 and -target 11 to javac
>>>>>          JDK-8193351: Add SourceVersion.RELEASE_11
>>>>> Please review the preliminary webrev and CSRs.
>>>> I don't see a change to the actual JDK version as part of this ?? 
>>> Correct; the webrev to date is the langtools portion of the new JDK 
>>> groundbreaking, the same subset of groundbreaking I looked at for the 
>>> 9 -> 10 transition. Other pieces are needed too, including HotSpot 
>>> changes and the actual version update.
>> So what is the overall transition strategy here? I don't see how you 
>> can change javac to default to -source/-target 11 prior to bumping the 
>> actual version to 11. Or do you expect all the additional pieces to 
>> come together at the same time?
> 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?


> HTH,
> -Joe
> [1] Way back when, the new -source/-target values were added without 
> simultaneously being made the default. This increased maintenance costs 
> of javac tests and led us to implement the current policy.

More information about the compiler-dev mailing list