Inspired by Actual Events: JDK 9 @Deprecated Annotation Enhancements
In the post What Might a New @Deprecated Look Like?, I used the description of JEP 277 ("Enhanced Deprecation") at that time to guide the creation of an enhanced customized @Deprecated annotation. Since that post, however, there have been significant changes made in JEP 277. This post summarizes the changes and the currently planned enhancements to @Deprecated that are slated for JDK 9.
The changes made to JDK-8065614 ("JEP 277: Enhanced Deprecation") on 2016-03-03 18:04 remove the portion of the JEP description that described the proposed @Deprecated enum. The "Alternatives" section of the main JEP 277 page documents why the enum was removed:
Previous versions of this proposal included a variety of "reason" codes including UNSPECIFIED, DANGEROUS, OBSOLETE, SUPERSEDED, UNIMPLEMENTED, and EXPERIMENTAL. These attempted to encode the reason for which an API was deprecated, the risks of using it, and also whether a replacement API is available. In practice, all of this information is too subjective be encoded as values in an annotation. Instead, this information should be described in the Javadoc documentation comment.
The revised @Deprecated annotation now supports two methods as shown in the API documentation. The documentation explains that the forRemoval() method "indicates whether the annvaluable otated element is subject to removal in a future version" and returns false by default. The since() method documentation states that this second method "returns the version in which the annotated element became deprecated" and returns empty string by default.
Read full article from Inspired by Actual Events: JDK 9 @Deprecated Annotation Enhancements
No comments:
Post a Comment