On 14/12/2017 1:51 PM, 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.
We can't do that.
src/java.base/share/native/include/classfile_constants.h is an exported
interface - at least at present - so it can't depend on something that
has to come from the build. You'd have to generate the exported version
with the appropriate value substituted.
David
-----
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
