RFR: JDK-8275308: Add valueOf(Runtime.Version) factory to SourceVersion [v2]

[Michael Bien]

On Sat, 16 Oct 2021 00:02:08 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> I wanted to get input on the design of API of the method before writing the tests.
>> 
>> The new factory method maps from a Runtime.Version object, a object which formally modes the version of the JDK, to a corresponding SourceVersion object.
>> 
>> Given the current histories of versioning of the JDK and SourceVersion this amount to mapping "JDK N" to RELEASE_N, for example, JDK 17 to RELEASE_17, etc. As mentioned in the API note, this could potentially change in the future if the release model changes. Runtime.Version has added in JDK 9, but earlier versions can be modeled. Note that no attempt is made to map "1.2" to RELEASE_2 and that since Runtime.Version grammar does not allow a leading 0 term, RELEASE_0 will *not* be returned by the new method.
>> 
>> Another design point: an out-of-range feature version is treated as an error so a Runtime.Version with a feature of 19 mapped in JDK 18 will fail with an IllegalArgumentException rather than saturating at RELEASE_18. If saturating would be more helpful for the envisioned use cases, I'm open to changing the spec accordingly.
>> 
>> CSR to follow once the API is nailed down.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typo.

although the new factory method is quite useful to convert from one version representation to another. Unfortunately, I don't think it would solve one particular use case (although a very niche one). NetBeans for example relies on javac for all its editor features and can optionally use a newer javac than the JDK has, on which it is running on. This allows to have java 17 editor features while starting NB on JDK 8 (for whatever reason). 

That is why you can find code like in https://github.com/apache/netbeans/pull/3166/commits/56cf1c5b4d9b770b7fe39a34be373c0d0165ae58 all over the place since it has to check a feature version against an enum which might not be there. And that is why my first thought went to "wouldn't it be nice if we could just compare ordinals or ask SourceVersion for the feature version int". Calling `version.feature() >= 11` would not require having access to the RELEASE_11 enum you would need to compare the version with. 

Calling `version.compareTo(SourceVersion.valueOf(Runtime.Version.parse("11")))) >= 0` wouldn't help a lot since it basically has to throw exceptions since it can't just make up enums.

But this is so niche that it is probably not worth considering.

NB could just put

   public static boolean supports(SourceVersion model, int featureVersionToCheck) {
       return model.ordinal() >= featureVersionToCheck;
   }

somewhere which will work until the unlikely event of the enum having non-feature versions before it needs to be changed. (or just keep doing the static initializer workaround)

-------------

PR: https://git.openjdk.java.net/jdk/pull/5973