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
