Build portability: enable or disable warnings

[Jonathan Gibbons]

On 05/19/2011 08:00 AM, Kelly O'Hair wrote:
> On May 19, 2011, at 11:32 AM, Alan Bateman wrote:
>
>> David Holmes wrote:
>>> :
>>>
>>>> In contrast, there are basically two Java compilers in general use (javac and ecj)
>>>> and one is part of OpenJDK.  Yet, the Java code does not have -Werror enabled by default and there
>>>> are a mass of warnings there as a result.
>>> I don't understand the point you are making here. Does javac even have a -Werror? The bulk of javac warnings stem from legacy code being compiled under newer compilers with new language features - the resulting code is not erroneous hence only a warning is issued.
>>>
>>> I think comparing C/C++ compiler warnings with javac compiler warnings is like comparing apples and elephants.
>> Yes, javac has -Werror and the build has JAVAC_WARNINGS_FATAL to turn it on. I just checked my recent build of the jdk7/jdk7 forest and javac emits a total of 9 warnings (7 are unsafe usages of varargs methods and the other two are unreachable catch clauses). That isn't a lot but javac doesn't have many warnings enabled by default. A nice project for someone would be to change the build to -Werror by default and gradually crank up the warnings listed by -Xlint.
> I noticed that some parts of the jdk build do use 'javac -Werror', where it was cleaned up they would turn on this flag.
>
> But yes, a great project would be to see if we could get to 'javac -Xlint:all -Werror' someday.
> We really should...  in fact it should be a requirement moving forward that all java code be warning free, and stay that way.

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.

-- Jon

> Not sure about the hotspot java code.
>
> -kto
>
>> -Alan.
>>
>>