New version schema and javax.lang.model.SourceVersion

[Robert Field]

Or, of course: 

RELEASE_18_3

Robert

Sent from my iPad

> On Sep 15, 2017, at 9:37 AM, joe darcy <joe.darcy at oracle.com> wrote:
> 
> Hi Volker,
> 
> Yes, SourceVersion and several other javac-related pieces of functionality may need to be updated to accommodate the new version scheme. For javac, the -source, -target, and --release values may need updating or aliases. For example, perhaps "10" and "18.3" and equivalent, just as "8" and "1.8" are equivalent today. The policies we've been following in JEP 182: "Policy for Retiring javac -source and -target Options," supporting a source/target value for the current release + three back, may or may not be updated as well.
> 
> The relative ordering of SouceVersion enum comes from their declaration order. We could have
> 
>    RELEASE_18_DOT_3
> 
> or even
> 
>    RELEASE_EIGHTEEN_DOT_THREE
> 
> but I don't think the last of these is very likely ;-)
> 
> Regards,
> 
> -Joe
> 
> 
>> On 9/15/2017 7:35 AM, Volker Simonis wrote:
>> Hi,
>> 
>> one minor glitch with the newly proposed version schema [1] (i.e.
>> 18.3, 18.9, etc.) is that we have the enum
>> javax.lang.model.SourceVersion which defines:
>> 
>> RELEASE_0 The original version
>> RELEASE_1 The version recognized by the Java Platform 1.1.
>> ...
>> RELEASE_9 The version recognized by the Java Platform, Standard Edition 9.
>> 
>> As we can't use periods in constant names we'll probably have to stick to
>> 
>> RELEASE_10 The version recognized by the Java Platform, Standard Edition 18.3.
>> RELEASE_11 The version recognized by the Java Platform, Standard Edition 18.9.
>> 
>> in the future. So Java 10, 11 etc. will at least stay with us forever
>> (and if only through this little known API :)
>> 
>> Regards,
>> Volker
>> 
>> [1] https://mreinhold.org/blog/forward-faster
>