JDK 13 RFR of JDK-8221264: Refactor SourceVersion#latestSupported
Joe Darcy
joe.darcy at oracle.com
Sat Mar 23 18:11:03 UTC 2019
Hello,
New version of the patch uploaded to
http://cr.openjdk.java.net/~darcy/8221264.1/
and in-line below.
I did consider adding a numeric version to the enum constants as one way
to address the issue, but considered that as excessive for the issue at
hand. I'm will to consider such field for other purposes, as Jon alludes to.
New API note added to latestSupported:
"This method is included alongside 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 N while running on platform version (N - 1).
Running in this configuration is supported by the API. Running an API on
platform versions earlier than (N - 1) or later than N may or may not
work as an implementation detail."
I wouldn't endorse any overt steps to prevent the language model API
from being able to be compiled and run on JDK versions other than N and
(N - 1) and it would most likely work on (N + 1) and later, but I want
to set expectations that there are no guarantees for a larger range.
Also, since the feature method was added in JDK 10, I tightened the
returned range to be JDK 10 or later.
I didn't do so in this patch, but it would be reasonable to bump
{@code RELEASE_5} or later must be returned.
to RELEASE_8 or later since the API using JDK 8 language features.
Thanks,
-Joe
---
old/src/java.compiler/share/classes/javax/lang/model/SourceVersion.java
2019-03-23 10:57:50.719498000 -0700
+++
new/src/java.compiler/share/classes/javax/lang/model/SourceVersion.java
2019-03-23 10:57:50.383330000 -0700
@@ -209,30 +209,10 @@
private static final SourceVersion latestSupported =
getLatestSupported();
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;
}
/**
@@ -240,6 +220,17 @@
* current execution environment. {@code RELEASE_5} 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() {
On 3/22/2019 11:46 AM, Jonathan Gibbons wrote:
>
> +1 on an RFE to get a numeric version from a source version, either
> now or in a follow-up RFE ... and potentially the reverse as well, to
> get a SourceVersion from a numeric argument. Both would help with
> analyzing and creating command-line arguments, without excessive
> string-bashing or side-maps.
>
> -- Jon
>
>
> On 03/22/2019 11:14 AM, Liam Miller-Cushon wrote:
>> 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
>> <http://cr.openjdk.java.net/%7Ecushon/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
>> <mailto: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/
>> <http://cr.openjdk.java.net/%7Edarcy/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/20190323/56d55501/attachment-0001.html>
More information about the compiler-dev
mailing list