> On 13 Dec 2017, at 19:51, mark.reinh...@oracle.com wrote:
>
> 2017/12/13 15:49:53 -0800, paul.san...@oracle.com:
>> On 13 Dec 2017, at 14:36, mark.reinh...@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.
>
Thanks, Eric’s patch takes this a few steps further and i will merge that into
mine.
>> 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.
Yes, given Runtime.Version's focus on representing a version string for the
platform.
> Parsing
> `System.getProperty("java.class.version")` every time is no fun.
>
Indeed. I’ll follow up on this yak shave with a separate issue.
Paul.
