getting a handle on build warnings

[Jonathan Gibbons]

Depending on what lint options you use, deprecation warnings are  
typically reported as a single "Note:" at the end of the compilation,  
rather than as individual warning messages.  Ideally, they should go  
too, but for now, I'd settle for removing messages that show up as  
diagnostics in IDEs, emacs, etc.

For my part, I work mostly in the langtools area,  and we are having a  
general background effort to clean up the code there. The goal is to  
clean the code and then use -Werror to treat any reappearance of  
warnings as errors.

-- Jon


On Jul 11, 2008, at 10:52 AM, Rob Ross wrote:

> Just curious, would part of this revision process entail removing  
> calls to deprecated methods and replacing them with their documented  
> replacement methods?
>
> There are many warnings about calls to deprecated methods in the  
> OpenJDK code.
>
>
> Rob Ross, Lead Software Engineer
> E! Networks
>
> ---------------------------------------------------
> "Beware of he who would deny you access to information, for in his  
> heart he dreams himself your master." -- Commissioner Pravin Lal
>
>
>
> On Jul 11, 2008, at 10:43 AM, Jonathan Gibbons wrote:
>
>>
>> On Jul 11, 2008, at 10:00 AM, Thorbjørn Ravn Andersen wrote:
>>
>>> Jonathan Gibbons skrev  den 11-07-2008 13:52:
>>>>
>>>> Yes, that technique can work well. But either way, the next step is
>>>> to try writing the code to analyze the build log, to see how far  
>>>> the general
>>>> idea can be taken, and how much interest there is to track/fix  
>>>> warnings.
>>>>
>>> Personally I'd like there to be no warnings at all, and would like  
>>> to contribute work to get there
>>>
>>
>> Thank you.
>>
>> Getting rid of the actual warnings will require cooperation from  
>> the teams who are
>> responsible for the various parts of the code. In some cases, there  
>> may be resistance,
>> since stability is sometimes preferred over "no warnings".  That  
>> being said, what I'm
>> hoping to achieve with this discussion and any related effort is a  
>> non-intrusive way
>> of gathering information about warnings, so that we have a better  
>> understanding of
>> where the warnings are, in what areas of the code and in which  
>> source files.  That way,
>> we can work with the teams involved to see if there is interest in  
>> reducing their
>> warning count in as safe a way as possible.  Any assistance in  
>> getting to that point
>> would be welcome.
>>
>> (Note that anyone contributing to OpenJDK must first sign the Sun  
>> Contributor Agreement;
>> you can find details at http://sca.dev.java.net.)
>>
>> -- Jon
>>
>>
>