Hello, 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. Gruss Bernd Am 04.12.2014 09:49 schrieb "joe darcy" <joe.da...@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 >
