JDK 13 RFR of JDK-8221264: Refactor SourceVersion#latestSupported

[Liam Miller-Cushon]

Thanks Joe,

This looks good to me overall, for what it's worth.

Some minor notes:

* I think it might still be helpful to capture some of your explanation
from the bug in the javadoc for latestSupported(), to help users understand
when the use of that method is appropriate.

* Your explanation of the lower bound might make a good implementation
comment to explain the use of RELEASE_9.

* Also, have you considered including the numeric feature version in the
enum constants in SourceVersion? It might avoid some of the hard-coded
version numbers in getLatestSupported. I'm imagining something along the
lines of:
http://cr.openjdk.java.net/~cushon/8221264/webrev.00/src/java.compiler/share/classes/javax/lang/model/SourceVersion.java.sdiff.html

On Fri, Mar 22, 2019 at 10:34 AM Joe Darcy <joe.darcy at oracle.com> wrote:

> Hello,
>
> Responding to an rfe filed by Liam, please review a refactoring of the
> SourceVersion.latestSupported method:
>
>      JDK-8221264: Refactor SourceVersion#latestSupported
>      http://cr.openjdk.java.net/~darcy/8221264.0/
>
> Patch below.
>
> With this version, when it comes time to rev a release for 14, the line
>
> +            return valueOf("RELEASE_" + Math.min(13, intVersion));
>
> will need to be changed to
>
> +            return valueOf("RELEASE_" + Math.min(14, intVersion));
>
> In general the JSR 269 packages, javax.lang.model and
> javax.annotation.processing, are constrained by bootstrapping issue to
> be runnable on JDK (N-1); in other words, they cannot only run on JDK N.
> It may or may not be possible to compile the code to run on JDK (N-2) or
> earlier. For example, since JDK 9, the JSR 269 API has used default
> methods so the API certainly cannot be compiled and run earlier than JDK 8.
>
> The Runtime.Version type was introduced in JDK 9; its feature() method
> in 10.
>
> The proposed implementation is simple, even if it is not completely
> accurate in a current lower bound for running the API; I don't think
> being more accurate on this lower bound is necessary.
>
> Thanks,
>
> -Joe
>
> ---
> old/src/java.compiler/share/classes/javax/lang/model/SourceVersion.java
> 2019-03-22 10:09:33.870668998 -0700
> +++
> new/src/java.compiler/share/classes/javax/lang/model/SourceVersion.java
> 2019-03-22 10:09:33.526668998 -0700
> @@ -209,30 +209,13 @@
>       private static final SourceVersion latestSupported =
> getLatestSupported();
>
>       private static SourceVersion getLatestSupported() {
> -        try {
> -            String specVersion =
> System.getProperty("java.specification.version");
> +        int intVersion = Runtime.version().feature();
>
> -            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;
> +        if (intVersion >= 10) {
> +            return valueOf("RELEASE_" + Math.min(13, intVersion));
> +        } else {
> +            return RELEASE_9;
> +        }
>       }
>
>       /**
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190322/68eb2978/attachment.html>