Hello,
On 12/13/2017 1:18 PM, mark.reinh...@oracle.com wrote:
2017/12/13 8:44:33 -0800, paul.san...@oracle.com:
On 12 Dec 2017, at 20:56, david.hol...@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
