Greetings,
I was tempted to address this point my initial message, but since it has
been raised I will do so now.
Many of the warnings in the JDK have been there for years or even more
than a decade in some cases. Therefore, historically those of us who
have worked on the JDK apparently have a very high tolerance for warning
messages ;-)
The better should not be the enemy of the good. Suppressing the warnings
can be done relatively quickly and the warnings can be turned on in the
build, preventing new warnings from being introduced. The subtasks of
JDK-8066618: Fix deprecation warnings in jdk libraries
contain a snapshot of the current deprecation warnings. Therefore,
information about the state of the deprecation warnings has been
captured and can be acted upon in due course.
-Joe
On 12/4/2014 9:09 AM, Bernd wrote:
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
