> On 13 Dec 2017, at 13:18, mark.reinh...@oracle.com wrote: > > 2017/12/13 8:44:33 -0800, paul.san...@oracle.com: >>> On 12 Dec 2017, at 20:56, david.hol...@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. Paul. > 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 > > @SupportedSourceVersion(SourceVersion.RELEASE_11) > > could be replaced by > > @SupportedSourceVersion(SourceVersion.RELEASE_CURRENT) > > 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
