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

[mark.reinhold at oracle.com]

2017/12/13 8:44:33 -0800, paul.sandoz at oracle.com:
>> On 12 Dec 2017, at 20:56, david.holmes at oracle.com wrote:
>> 
>> 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?
> 
> No yet, i was hoping we could consolidate as much as possible under
> one issue thereby minimising coordination/process i.e. combine the
> release and class file versions under one patch. Then stand back and
> see what is missing e.g. ctsym stuff etc.

How much of this can we parameterize and/or automate?  We are going to
have to do it every six months, after all.

Could we define a CLASSFILE_VERSION in make/autoconf/version-numbers and
then propagate that value everywhere else?  (In any actual release it'll
be VERSION_FEATURE + 44, but make it a separate variable to allow for
experimentation as with, e.g., MVT.)

Looking at Joe's webrev, many of the changes from 10 to 11 could instead
be changed to Runtime.getRuntime().version().major() (in Java code) or
VERSION_FEATURE (in Makefiles).

In javax.lang.model.SourceVersion we could define a new constant, say
RELEASE_CURRENT, whose value is that of the latest release.  Then
annotations such as

  @SupportedSourceVersion(SourceVersion.RELEASE_11)

could be replaced by

  @SupportedSourceVersion(SourceVersion.RELEASE_CURRENT)

Similarly, JDK_CURRENT could be defined in com.sun.tools.javac.Target
and then many references to JDK10 could instead refer to that.

In cases where additional code is needed, can we generate it during
the build via another Gensrc*.gmk Makefile?  That'd be more work now,
but it could save us a lot of time in the long run.

- Mark