SourceVersion::feature

[Michael Bien]

thank you! I replied on the PR.
-michael

On 16.10.21 01:19, Joseph D. Darcy wrote:
> PS See https://github.com/openjdk/jdk/pull/5973
>
> -Joe
>
> On 10/14/2021 1:53 PM, Joseph D. Darcy wrote:
>> On 10/14/2021 10:23 AM, Michael Bien wrote:
>>> is this the right mailing list for javax.lang.model.* discussions?
>>
>>
>> The compiler-dev list would be appropriate as well, but core-libs 
>> will work.
>>
>> First, I understand the desire for a method like this. One of the 
>> potential issues is SourceVersion models language versions and while, 
>> to date, there has been a simple linear progression, that is not 
>> guaranteed to be case arbitrarily far into the future, even though it 
>> is the most likely outcome.
>>
>> Since java.lang.Runtime.Version is in the platform now, I think this 
>> request would be better satisfied via a
>>
>>     public static SourceVersion valueOf(Runtime.Version version)
>>
>> method on SourceVersion. That way the modeling of SourceVersion can 
>> absorb any non-linearity in versioning and presumably provide 
>> sufficient information for a  Runtime.Version -> SourceVersion 
>> mapping to query.
>>
>> I've filed the RFE
>>
>>     JDK-8275308: Add valueOf(Runtime.Version) factory to SourceVersion
>>
>> Cheers,
>>
>> -Joe
>>
>>
>>>
>>> if yes:
>>>
>>> instead of adding
>>>     /**
>>>      * Returns the version as int representing the feature release.
>>>      * @see Runtime.Version#feature()
>>>      */
>>>     public int feature() {
>>>         return this.ordinal();
>>>     }
>>> to SourceVersion.
>>>
>>> a note could be added to the doc that the ordinal can be used as 
>>> feature version. Since this statement would apply to the past too, 
>>> the note could be backported to all maintained JDKs. This comes with 
>>> the usual downside of not being able to add enums for in-between 
>>> versions in future.
>>>
>>> (doing both would be an option too of course)
>>>
>>>
>>> To not use the ordinal, client code has to go through some enum init 
>>> rituals to be able to do version comparisons:
>>>
>>>    final static SOURCE_VERSION_RELEASE_18;
>>>    static {
>>> SourceVersion tmp18;
>>>         try {
>>>             tmp18 = SourceVersion.valueOf("RELEASE_18");
>>>         } catch (IllegalArgumentException ex) {
>>> tmp18 = null;
>>>         }
>>>         SOURCE_VERSION_RELEASE_18 = tmp18;
>>>         //... more versions
>>>    }
>>> just to be able to
>>>
>>>     if (SOURCE_VERSION_RELEASE_18 != null && 
>>> version.compareTo(SOURCE_VERSION_RELEASE_18) >= 0) {}
>>>
>>> or
>>>
>>>     if 
>>> (Integer.parseInt(version.name().substring(version.name().indexOf('_')+1)) 
>>> >= 18) {}
>>>
>>> which is shorter but not a good solution either.
>>>
>>> what the client code actually wants is:
>>>
>>>     if (SourceVersion.latest().feature() >= 18) {}
>>>
>>>
>>> it was a wise decision for java.lang.Runtime.Version to not use 
>>> enums :)
>>>
>>> best regards,
>>> michael
>>>
>>>
>>>
>>> On 09.10.21 20:58, Michael Bien wrote:
>>>> Hello,
>>>>
>>>> could javax.lang.model.SourceVersion receive a feature() method 
>>>> returning the version as an int, analog to java.lang.Runtime.Version?
>>>>
>>>> if (SourceVersion.latest().feature() >= 18) {}
>>>>
>>>> is simpler than comparing enums which may or may not exist 
>>>> dependent on the deployed java version and cleaner than ordinal() 
>>>> tricks.
>>>>
>>>> best regards,
>>>>
>>>> michael
>>>>