JEP 277: Enhanced Deprecation

[Alex Buckley]

On 10/28/2015 1:24 PM, mark.reinhold at oracle.com wrote:
> New JEP Candidate: http://openjdk.java.net/jeps/277

- Should I be able to say CONDEMNED regardless of the reason why an API 
is being deprecated ("don't know", "obsolete", "superseded") ? You don't 
state that for UNSPECIFIED ("don't know").

- DANGEROUS and UNIMPLEMENTED criticize the actual functionality of an 
API, which is far less meta than the reasons for deprecation above. 
Suppose you decide to deprecate a method for being DANGEROUS, and are 
able to mark it SUPERSEDED -- it's possible the replacement might be 
DANGEROUS too, but would never be SUPERSEDED too.

(Another angle. I can think of many other critical terms for signatures 
(USES_RAW_TYPES, INAPPROPRIATE_USE_OF_OPTIONAL) and implementations 
(SLOW, INSECURE) -- whereas the following two notices cover the ground 
completely: "Without telling you why, I suggest you don't use this; 
there is no replacement" and "Without telling you why, I suggest you 
don't use this; there is a replacement". Things like DANGEROUS and SLOW 
are in the "telling you why" business.)

- Consider one of the circumstances detailed by JLS 9.6.4.6 for NOT 
giving a deprecation warning: "The use is within an entity that is 
itself annotated with the annotation @Deprecated". Does this apply 
regardless of the reasons for the inner and outer deprecations?

- Consider the effect on @SuppressWarnings("deprecation").

- Suggest s/JRE/Java runtime/g.

Alex