> On 13 Dec 2017, at 14:36, mark.reinh...@oracle.com wrote: > > 2017/12/13 14:09:44 -0800, paul.san...@oracle.com: >>> On 13 Dec 2017, at 13:18, mark.reinh...@oracle.com wrote: >>> 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. > > 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 :-) 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? 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? Paul.
