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:
http://cr.openjdk.java.net/~darcy/8173382.1/
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?
Thanks,
David
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.
