JDK 13 RFR of JDK-8221264: Refactor SourceVersion#latestSupported
Joseph D. Darcy
joe.darcy at oracle.com
Tue Mar 26 02:45:42 UTC 2019
Pushed with some additional clarifications discussed with Jon off-list:
http://hg.openjdk.java.net/jdk/jdk/rev/44edf64cb206
Thanks,
-Joe
On 3/25/2019 4:41 PM, Liam Miller-Cushon wrote:
> +1, thanks!
>
> On Mon, Mar 25, 2019 at 4:34 PM Jonathan Gibbons
> <jonathan.gibbons at oracle.com <mailto:jonathan.gibbons at oracle.com>> wrote:
>
> Looks good to me.
>
> -- Jon
>
>
> On 03/25/2019 09:41 AM, Joe Darcy wrote:
> > Hello,
> >
> > Hopefully the final iteration of this patch; updated materials:
> >
> > 8221264 Refactor and update SourceVersion.latestSupported
> > http://cr.openjdk.java.net/~darcy/8221264.2/
> <http://cr.openjdk.java.net/%7Edarcy/8221264.2/>
> > NEW! CSR https://bugs.openjdk.java.net/browse/JDK-8221415
> >
> > I added a comment citing JEP 322: "Time-Based Release
> Versioning" to
> > justify the new implementation.
> >
> > A CSR is needed because of the update to the minimum version
> returned,
> > just an @apiNote would not necessarily need a CSR as the changes
> would
> > be informative rather than normative.
> >
> > The particular implementation below would only work on JDK 10 and
> > higher as it uses a method added in JDK 10. However, the
> lower-bound
> > of latest supported is raised to JDK *9* rather than JDK 10
> since an
> > independent implementation of the API could be written to run and
> > compile against 9.
> >
> > A few additional comments. The most common way of using the
> > javax.lang.model API is expected to be the version bundled in
> the JDK.
> > There is one particular other use case that has always intended
> to be
> > supported by JSR 269, namely running the API from JDK N on JDK
> (N-1)
> > assuming the user had their own compilation of the API. If other
> > mix-and-match use cases work that is fine - and the new
> implementation
> > should accurately support a larger number of reasonable
> combinations -
> > but it is a non-goal to impose any additional engineering
> constraints
> > on the evolution of the API to maximize the range of JDKs it can be
> > run on.
> >
> > Patch below.
> >
> > Thanks,
> >
> > -Joe
> >
> > ---
> >
> old/src/java.compiler/share/classes/javax/lang/model/SourceVersion.java
>
> > 2019-03-25 08:53:35.544735632 -0700
> > +++
> >
> new/src/java.compiler/share/classes/javax/lang/model/SourceVersion.java
>
> > 2019-03-25 08:53:35.220573632 -0700
> > @@ -58,7 +58,7 @@
> > * 9: modules, small cleanups to 1.7 and 1.8 changes
> > * 10: local-variable type inference (var)
> > * 11: local-variable syntax for lambda parameters
> > - * 12: TBD
> > + * 12: no changes (switch expressions in preview)
> > * 13: TBD
> > */
> >
> > @@ -208,38 +208,36 @@
> >
> > private static final SourceVersion latestSupported =
> > getLatestSupported();
> >
> > + /*
> > + * The integer to release enum constant implemented by this
> method
> > + * assumes the JEP 322: "Time-Based Release Versioning"
> scheme is
> > + * in effect. This scheme began in JDK 10. If the JDK
> versioning
> > + * scheme is revised, this method may need to be updated
> > + * accordingly.
> > + */
> > private static SourceVersion getLatestSupported() {
> > - try {
> > - String specVersion =
> > System.getProperty("java.specification.version");
> > -
> > - switch (specVersion) {
> > - case "13":
> > - return RELEASE_13;
> > - case "12":
> > - return RELEASE_12;
> > - case "11":
> > - return RELEASE_11;
> > - case "10":
> > - return RELEASE_10;
> > - case "9":
> > - return RELEASE_9;
> > - case "1.8":
> > - return RELEASE_8;
> > - case "1.7":
> > - return RELEASE_7;
> > - case "1.6":
> > - return RELEASE_6;
> > - }
> > - } catch (SecurityException se) {}
> > -
> > - return RELEASE_5;
> > + int intVersion = Runtime.version().feature();
> > + return (intVersion >= 11) ?
> > + valueOf("RELEASE_" + Math.min(13, intVersion)):
> > + RELEASE_10;
> > }
> >
> > /**
> > * Returns the latest source version fully supported by the
> > - * current execution environment. {@code RELEASE_5} or
> later must
> > + * current execution environment. {@code RELEASE_9} or
> later must
> > * be returned.
> > *
> > + * @apiNote This method is included alongside {@link latest} to
> > + * allow situations where the language model API is running
> on a
> > + * platform version different than the latest version
> modeled by
> > + * the API to be identified. One way that sort of situation can
> > + * occur is if a IDE or similar tool is using the API to model
> > + * source version <i>N</i> while running on platform version
> > + * (<i>N</i> - 1). Running in this configuration is
> > + * supported by the API. Running an API on platform versions
> > + * earlier than (<i>N</i> - 1) or later than <i>N</i>
> > + * may or may not work as an implementation detail.
> > + *
> > * @return the latest source version that is fully supported
> > */
> > public static SourceVersion latestSupported() {
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190325/5ae7c43b/attachment-0001.html>
More information about the compiler-dev
mailing list