Build portability: enable or disable warnings

[Alan Bateman]

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.