getting a handle on build warnings

[Kelly O'Hair]

+1 from me.

---

It might help that when people do remove some of the more tricky
warnings, that they send a short email on how they did it.
I remember having to walk down the hall to see Peter Ahe a few times
when I was trying to get rid of some of the trickier warnings in some
of my java code.
Using the annotation to suppress the warning should be a last resort.

-kto

Jonathan Gibbons wrote:
> The point is noted, but it seems to me that it would be better to
> work on removing warnings rather than making it even easier
> to continue ignoring them :-)
> 
> With the possible exception of the obnoxious proprietary API
> warnings from javac (which typically do not occur in the build
> anyway), all warnings from javac  can be eliminated one way or
> another, and we should be doing all we can to have developers
> eliminate the warnings in the code for which they are responsible.
> Even if we can't clean all the warnings from all the files, I think
> it is reasonable to remove all the warnings from any file a
> developer edits.
> 
> -- Jon
> 
> Martin Buchholz wrote:
>> One significant simple annoyance is that compile errors are hard to find
>> amongst the mass of warnings, because errors are not identified as such.
>> It would be very nice if errors were prefixed by "error:" the same
>> way that warnings are prefixed by "warning:",
>> making them easy to search for.
>>
>> Martin
>>   
>