Moar updates to JEP 277 - Enhanced Deprecation - warnings policy

Christoph Engelbert chris at hazelcast.com
Tue Aug 23 04:57:43 UTC 2016


Hey Stuart,

Nice work, anyhow I wonder if there’s any idea how to deal with @SuppressWarnings(“all”) even though I hope people are not really using it. Is it handled like “shoot yourself in the foot”? :-)

Chris

> On 23 Aug 2016, at 04:29, Stuart Marks <stuart.marks at oracle.com> wrote:
> 
> Hi all,
> 
> I've updated the JEP 277 text once again, this time focused on the policy for issuing deprecation warnings. See the revised JEP text in the bug report:
> 
>    https://bugs.openjdk.java.net/browse/JDK-8065614
> 
> Specifically the following sections have been rewritten:
> 
> - Deprecation vs. Introduction of Warning Messages
> - Impact of forRemoval on Warning Messages Policy
> - Suppression of Deprecation Warnings
> 
> The material in these sections is not actually new; the previous version talked about these issues, but it was so terse as to be unintelligible.
> 
> TL;DR: If code uses an API deprecated with forRemoval=true, the resulting warnings are not suppressed with the currently defined
> 
>   @SuppressWarnings("deprecation")
> 
> annotation. Instead, these warnings can be suppressed with a different annotation,
> 
>    @SuppressWarnings("removal")
> 
> The reason is that, if a deprecation warning is already suppressed with @SW("deprecation"), and the API is then "upgraded" to have forRemoval=true, this change will go unnoticed at use sites. This could lead to errors.
> 
> See the JEP text for further details.
> 
> s'marks



More information about the jdk9-dev mailing list