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
