Jonathan Gibbons wrote
There's a useful interim milestone which is relatively trivial to
do. If javac -Xlint:all gives warnings, you can go javac
-Xlint:all,-xyz to disable the xyz category of warnings. The specific
value of xyz to use is given at the beginning of the warning message
in square brackets. If you go through and do this, you will have
categorized the warnings that occur, and can work on fixing the
categories one at a time -- and removing the corresponding entry from
the -Xlint option. Note also that sometimes warnings are unavoidable,
but individual instances can be suppressed within the Java code using
the @SuppressWarnings("xyz") annotation. The values for the argument
of the @SuppressWarnings annotation are the same words that you can
use for -Xlint and which occur in the warning messages.
I recently built the jdk7 forest with -Xlint:all,-deprecation and the
number of warnings that javac spat out jumped from 9 to about 3300. I
didn't do a detailed analysis on the warnings except to observe that
about half of them were rawtypes warnings. The second most common one
seemed to be unchecked calls or conversions, and bulk of the others were
redundant casts or missing serialVersionUID. Most of these are easily
fixed, just needs someone to roll up their sleeves and get it done.
Your approach could work but it would be a big step to remove -rawtypes
and -unchecked from the list. Another idea is to start out by enabling
-Xlint:all,-deprecation,-serial so that the 3000+ warnings are laid bare
initially. That would encourage folks to address the warnings, at least
in the areas that they are working on. Once the numbers down to
something manageable then someone could kill off the remaining and turn
on -Werror. I'm sure there many other ways too. The important thing is
that I think we all agree this needs to be done and addressing the javac
warnings is a lot easier than addressing the warnings that we have with
the native code.
-Alan.
