JDK 9 RFR of JDK-8066617: Suppress deprecation warnings in java.base module

Bernd ecki at zusammenkunft.net
Thu Dec 4 17:09:37 UTC 2014


I am not sure this is a good idea, while I can understand a policy of "no
(new) lint warnings" and also activities to remove them (based on the
asumption that every warning is a potential bug or code smell) I absolutely
think supressing all remaining warnings without working to resolve them
(i.e. w/o evaluating) is a bad thing. First of all it does not improve code
quality but glutter it. Secondly it makes it impossible later on to
distinguish between well considered supressions and mass supressions.

I would instead favor a solution which can easily detect if any change does
add more/new warnings and fail the review for it. (I.e. baselining the
current warnings which is yet another option you will kill when you supress
them all). The original JEP does BTW not even mention the possibility of
using supression.

Am 04.12.2014 09:49 schrieb "joe darcy" <joe.darcy at oracle.com>:

> Hello,
> First some background, one of the JEPs targeted to JDK 9 is
>     JEP 212: Resolve Lint and Doclint Warnings
>     http://openjdk.java.net/jeps/212
> In the jdk repository, only the deprecation category of lint warnings
> remain. While resolving the other categories of warnings mostly involved
> area-agnostic Java language expertise (say, to generify an API), fixing a
> deprecation warning by modifying code often involves very detailed
> area-specific knowledge. For that reason, to resolve the deprecation
> category of lint warnings, rather than updating the code per se, I'm only
> planning to @SuppressWarnings the issues. To track that work, I've filed
> the umbrella bug
>     JDK-8066616: Suppress deprecation warnings in jdk libraries
>     https://bugs.openjdk.java.net/browse/JDK-8066616
> with subtasks for different modules in the build. I've also filed a
> sibling umbrella bug
>     JDK-8066618: Fix deprecation warnings in jdk libraries
>     https://bugs.openjdk.java.net/browse/JDK-8066618
> which has a matching set of subtasks to have each deprecation location in
> the code be reexamined by someone familiar with the area.
> With that background, first up is this review request for
>     JDK-8066617: Suppress deprecation warnings in java.base module
>     http://cr.openjdk.java.net/~darcy/8066617.0/
> Thanks,
> -Joe

More information about the core-libs-dev mailing list