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

Paul Sandoz paul.sandoz at
Wed Dec 13 22:09:44 UTC 2017

> On 13 Dec 2017, at 13:18, mark.reinhold at wrote:
> 2017/12/13 8:44:33 -0800, paul.sandoz at
>>> On 12 Dec 2017, at 20:56, david.holmes at 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?

I suspect quite a bit, as you present below, and i agree we should try and automate as much as possible. At the moment it’s very spaghetti-like and quite fragile.

I suggest we get the initial version bump for 11 out of the way as soon as JDK 10 branches off from the mainline then work on automation for subsequent releases.


>  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
> 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 873 bytes
Desc: Message signed with OpenPGP
URL: <>

More information about the compiler-dev mailing list