New version schema and javax.lang.model.SourceVersion

[joe darcy]

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