updates to JEP 277 - Enhanced Deprecation

Stuart Marks stuart.marks at oracle.com
Wed Jul 27 05:59:00 UTC 2016


Hi all,

I've done a major update to the text of JEP 277.[1] Most of this is to reflect 
the reality of what's happening in JDK 9, and some of it is tying off of loose ends.

The most significant change is around the treatment of warning messages mandated 
by the JLS (9.6.4.6). Currently, deprecation warnings can be suppressed with 
@SuppressWarnings("deprecation"). Currently, this suppresses warnings even if 
the API is deprecated with forRemoval=true. This is a problem, since the removal 
warning might be missed, leading to unexpected compile-time or run-time errors 
when the API is actually removed.

The proposal is to have uses of APIs deprecated for removal generate warnings 
anyway, even within code that as @SuppressWarnings("deprecation").

These new "deprecation for removal" warnings can in turn be suppressed using a 
different warnings suppression string,

     @SuppressWarnings("dep-removal")

The idea is that you get a warning for use of a for-removal deprecated API, even 
if you've previously suppressed the warning. Essentially you have to suppress it 
again if you want to continue using the API warning-free. This is somewhat 
intrusive, but I think it's warranted, given the gravity of the for-removal 
deprecation.

Highlights of other changes to the JEP include:

* update terminology from "condemned" to "forRemoval"

* new material on policy for usage of @Deprecated in Java SE, particularly with 
regarding to forRemoval=true

* updated list of deprecation candidates, with specific references to APIs being 
deprecated in Java SE 9

* removal of dynamic deprecation detection usage tool from JDK 9, for lack of 
time :-(

* new material describing issues with warning messages

s'marks


[1] https://bugs.openjdk.java.net/browse/JDK-8065614


More information about the jdk9-dev mailing list