Build portability: enable or disable warnings

[David Holmes]

Dr Andrew John Hughes said the following on 05/20/11 06:24:
> On 09:47 Thu 19 May     , David Holmes wrote:
>> Dr Andrew John Hughes said the following on 05/19/11 05:29:
>>> On 08:35 Mon 16 May     , Kelly O'Hair wrote:
>> <snip>
>>>> The -Werror option is a blessing and a curse. I find it highly commendable that teams (like 
>>>> hotspot) have taken a 'no warnings allowed' approach to their code base, more teams should do this.
>>>> Given the critical nature of a VM in the JDK, it only makes sense to take all precautions in verifying the code is correct.
>>>>
>>> I find it quite interesting that the one situation where -Werror is used is where it's likely to hit
>>> the most difficulties. The HotSpot code is compiled by three different compilers (gcc and whatever
>>> is used on Solaris and Windows) and the version of these used can vary considerably, as the system C++ compiler
>>> is unrelated to the JDK.  
>> Hotspot only uses -Werror with gcc. And its use predates the sudden 
>> plethora of compiler versions now used to build OpenJDK. In prior times 
>> the build compiler for a given release was set in stone so we knew what 
>> warnings (and bugs!) to expect. 
> 
> Welcome to OpenJDK.  You can't expect everyone compiling a FOSS project to
> use one true compiler and no other.  Sorry.  That's just the reality, and
> it's why we now have to reassess/amend these earlier choices.

I was simply stating the history.

<snip>
> It does.  I'm unclear how anything you say here is different to the situation
> with C/C++ compilers producing new warnings in new versions.

I'm unclear what point you are trying to make about javac.

javac produces new warnings because new language features cause new 
potential issues. There are no new features in C/C++ (compiler-specific 
extensions ignored), the compilers just get more pedantic about what 
they complain about.

>  If anything, OpenJDK
> is leading the way with support for these new language features, so you'd expect
> it to adopt them in its own codebase.  As is, we're still getting warnings resulting
> from features introduced in 2004.

Practical realities - there were no resources, for example, to go and 
change every single class that used a collection type in 1.4.2 and so 
generated a "raw type" warning once generics were added in 5. These 
things sometimes get cleaned up when other work is occurring in an area.

Also note that in many cases javac warnings are disappearing because 
@SuppressWarnings is being applied to the code.

David
-----

> 
>> I think comparing C/C++ compiler warnings with javac compiler warnings 
>> is like comparing apples and elephants.
>>
>> David
>> -----
>>
>