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
