RFR: JDK-8192963/JDK-8206986 JEP 325: Switch Expressions (Preview)

Jan Lahoda jan.lahoda at oracle.com
Mon Jul 30 12:32:22 UTC 2018

On 28.7.2018 01:34, Alex Buckley wrote:
> On 7/27/2018 4:12 PM, Jonathan Gibbons wrote:
>> Lots of @Deprecated annotations without corresponding @deprecated
>> javadoc tag. Should the @apiNote really be @deprecated. I also think
>> that using @Deprecated like this is "a bit smelly", and had a
>> discussion with Stuart "Dr Deprecator" regarding my concerns. If
>> nothing else, assuming the feature is a success, we are setting up a
>> precedent of marking an API as deprecated-for-removal, and then in
>> the next release, simply removing the annotation.
> JEP 12 is prepared to do exactly that for a Java SE API introduced in
> close connection with a preview feature -- see
> http://openjdk.java.net/jeps/12#Relationship-to-Java-SE-APIs.
> However, com.sun.source.tree is a JDK-supported API, not a Java SE API,
> so JEP 12 is silent on whether new methods in BreakTree.java and
> CaseTree.java should be flagged as if on the same level as a java.* API
> in the "Reflective" bucket. You could argue that a client of
> com.sun.source.tree is informed enough that they don't hand-holding
> about preview features.

One of my goals here was to keep the approach consistent and predictable 
between the API kinds. Even though JEP 12 does not speak about the 
com.sun.source APIs, using the same set of rules for both com.sun.source 
and javax.lang.model seems sensible to me.


> Alex

More information about the compiler-dev mailing list