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 15:49:53 -0800, paul.sandoz at oracle.com:
> On 13 Dec 2017, at 14:36, mark.reinhold at oracle.com wrote:
>> I understand that other incoming changes are waiting for the 11 version
>> bump, but can't we at least do the straightforward parameterizations and
>> introduce _CURRENT constants in this round?  We can leave anything that
>> requires code generation to post-11.
> 
> On the lang tools side that does seem easy, but I’ll defer to Joe.
> 
> With some guidance from the build engineers i would gladly consolidate
> class file version declaration in C/++ files with a passed in macro,
> if this can be expediently worked out. I wanna push condy as early as
> possible in 11 :-)

Understood, but let's do the right thing (or at least closer to that)
with this yak while we're here.

> If we could do something in jvm.h that would be ideal. We already have
> the definitions JVM_CLASSFILE_MAJOR_VERSION and
> JVM_CLASSFILE_MINOR_VERSION pulled in via classfile_constants.h, so
> how can the build process inject values into those macros?

I just went through this for the versioning changes.  The attached patch
(against d2a837cf9ff1) does what you want, I think.

> For class file versions embedded in Java code it would make it easier
> if we had programmatic access. Perhaps we could have static methods on
> Runtime.Version to get the major/minor class file versions?

Sure, or maybe better to make them instance methods of Runtime.  Parsing
`System.getProperty("java.class.version")` every time is no fun.

- Mark
-------------- next part --------------
A non-text attachment was scrubbed...
Name: conf-cf-version
Type: text/x-patch
Size: 4563 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20171213/d5ca5fab/conf-cf-version.bin>