Initial JDK 11 RFR of JDK-8173382: Add -source 11 and -target 11 to javac - Java Bug System & JDK-8193291: Add SourceVersion.RELEASE_11

[joe darcy]

Hello,


On 12/13/2017 1:18 PM, mark.reinhold at oracle.com wrote:
> 2017/12/13 8:44:33 -0800, paul.sandoz at oracle.com:
>>> On 12 Dec 2017, at 20:56, david.holmes at oracle.com wrote:

[snip]

>>>
>>> Looking at Joe's webrev, many of the changes from 10 to 11 could instead
>>> be changed to Runtime.getRuntime().version().major() (in Java code) or
>>> VERSION_FEATURE (in Makefiles).
>>>
>>> In javax.lang.model.SourceVersion we could define a new constant, say
>>> RELEASE_CURRENT, whose value is that of the latest release.  Then
>>> annotations such as
>>>
>>>    @SupportedSourceVersion(SourceVersion.RELEASE_11)
>>>
>>> could be replaced by
>>>
>>>    @SupportedSourceVersion(SourceVersion.RELEASE_CURRENT)
>>>
>>> Similarly, JDK_CURRENT could be defined in com.sun.tools.javac.Target
>>> and then many references to JDK10 could instead refer to that.
>>>
>>> In cases where additional code is needed, can we generate it during
>>> the build via another Gensrc*.gmk Makefile?  That'd be more work now,
>>> but it could save us a lot of time in the long run.
>>>

Some comments on the design of javax.lang.model API. The SourceVersion 
enum type has two methods

     latest()
     latestSupported()

The former returns the value corresponding to the proposed 
RELEASE_CURRENT. The latter's behavior is a bit more complicated and 
depends on the version of JDK upon which the javax.lang.model API is 
running. (It is supported and technically possible to run the 
javax.lang.model API from JDK (N+1) on top of JDK N; in that case 
latestSupported() returns RELEASE_{$N} rather than RELEASE_{$N+1}.)

By design, the results of SourceVersion. latest() are not a JLS 15.28 
"Constant Expressions" [1] and thus cannot be used to populate 
annotations directly. During JSR 269 we did consider defining a constant 
or enum constant like RELEASE_CURRENT, but rejected this for a few 
reasons. First, this value would not be a constant across time since the 
current release keeps changing. Given the compile-constants-into-class 
files behavior of javac, in general there would be subtle source 
compatibility implications to evolving the constant. In particular, a 
recompile would be necessary to pick up the revised "constant" value.

One intended use of the SourceVersion enum constants is for annotation 
processors to indicate which source versions they support as part of the 
processor <-> compiler handshake described in 
javax.annotation.processing.Processor. Supporting a new source version 
can require nontrivial updates to the logic of a processor since new 
kinds of constructs can be added to the language. Therefore, it would 
also be an attractive nuisance to make annotating a processor type with 
@SupportedSourceVersion(SourceVersion.RELEASE_CURRENT) too easy since 
the claim could easily not be true.

(Processors can get this effect today if they override 
AbstractProcessor.getSupportedSourceVersion() to return 
SourceVersion.latest() or write their own Processor implementation from 
scratch to do so.)

For these reasons, I don't think it is prudent to have a public API for 
RELEASE_CURRENT as a constant. However, it is reasonable in limited 
contexts such as within the javac testing code to use that patterns and 
I'll adjust the next iteration of the webrev accordingly.

Cheers,

-Joe

[1] https://docs.oracle.com/javase/specs/jls/se9/html/jls-15.html#jls-15.28

[2] 
http://download.java.net/java/jdk10/docs/api/javax/annotation/processing/Processor.html