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 at oracle.com
Wed Dec 13 22:09:44 UTC 2017
> On 13 Dec 2017, at 13:18, mark.reinhold at oracle.com wrote:
> 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?
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
> could be replaced by
> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 873 bytes
Desc: Message signed with OpenPGP
More information about the compiler-dev