Build portability: enable or disable warnings

[Dr Andrew John Hughes]

On 07:20 Fri 20 May     , David Holmes wrote:
> 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.
> 

Ah, ok.  It read to me as if you expected this to still be possible.

> <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.
> 

My point was just that it's interesting that it's HotSpot, which is
subject to the most variance in compilers (and thus the warnings
produced) that opts to have -Werror on by default.  The Java code
doesn't, yet the compiler for it is actually developed as part of the
OpenJDK code base.  It's not going to see the same kind of problem
where someone installs the new version of the system compiler and gets
new warnings, so -Werror behaviour with Java code would be much more
stable.

I don't think all javac warnings are down to new language features
and, having most warnings turned off and not causing errors, means
that more warnings build up as new code is written.

> >  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.
> 

I understand that.  It actually makes for some pretty good low hanging
fruit for external contributors to OpenJDK IMHO.  It's akin to the
janitoral work done on Linux if you're familiar with that.

I did find it worrying that there was an active desire to use new
OpenJDK7 language features throughout the codebase (despite the
bootstrapping problems this can cause), yet these 1.5 issues remain.

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

-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and IcedTea
http://www.gnu.org/software/classpath
http://icedtea.classpath.org
PGP Key: F5862A37 (https://keys.indymedia.org/)
Fingerprint = EA30 D855 D50F 90CD F54D  0698 0713 C3ED F586 2A37