Re: Build portability: enable or disable warnings
David Holmes wrote: : In contrast, there are basically two Java compilers in general use (javac and ecj) and one is part of OpenJDK. Yet, the Java code does not have -Werror enabled by default and there are a mass of warnings there as a result. I don't understand the point you are making here. Does javac even have a -Werror? The bulk of javac warnings stem from legacy code being compiled under newer compilers with new language features - the resulting code is not erroneous hence only a warning is issued. I think comparing C/C++ compiler warnings with javac compiler warnings is like comparing apples and elephants. Yes, javac has -Werror and the build has JAVAC_WARNINGS_FATAL to turn it on. I just checked my recent build of the jdk7/jdk7 forest and javac emits a total of 9 warnings (7 are unsafe usages of varargs methods and the other two are unreachable catch clauses). That isn't a lot but javac doesn't have many warnings enabled by default. A nice project for someone would be to change the build to -Werror by default and gradually crank up the warnings listed by -Xlint. -Alan.
Re: Build portability: enable or disable warnings
On 5/18/2011 12:23 PM, Dr Andrew John Hughes wrote: On 07:25 Mon 16 May , Erik Trimble wrote: On 5/16/2011 6:03 AM, Andrew Haley wrote: On 05/16/2011 12:08 PM, Dalibor Topic wrote: The reason I'm asking is that I'm wondering if this is something we should expect to crop up in different parts of the code base, or whether it's a one off due to some specific thing some distros chose to do different from each other. That's hard to say. It certainly could crop in other parts of the code base, and I'm surprised it doesn't happen regularly. I'm rather appalled that distros do this kind of thing, TBH. Andrew. Just so I understand this - you're saying that by running *just* the 'gcc' command on different linux systems, that actually implies that gcc gets invoked with some set of flags already set? And, that there's no way to just invoke "vanilla" gcc ? If so, that's, ah, mindboggling (not in a good way)... Maybe I'm misreading what you said, but I don't find it mindboggling that an application would have default settings for certain options. That's basically what we're talking about here. If a warning can be either on or off, then one of these two has to be a default for that exact situation when the user does just say "gcc" and doesn't specify whether they want the warning or not. Yes, but gcc isn't *just* an application, it's an application *builder*. If people want to pay more than lip service to portability, then the defaults set for such an entity should be ONLY those which are universal - that is, distro A should never be setting defaults that distros B & C don't also set. Given the current state of things, that means gcc should only be set with the defaults that the GNU folks set, and NOT anything specific to a distro. If a distro wants something specific in the way of flags for itself, it should have a wrapper or some such for itself to call, but the generic 'gcc' should behave EXACTLY as it does on all other platforms. This applies to all "builder" programs (ld, cpp, et al.) Unless of course, portability isn't a concern, which, frankly, for many Linux distros, doesn't seem to be anywhere on their radar. A number of distros change the defaults of gcc in order to produce more warnings, as some can point to real security issues. This runs afoul of HotSpot's use of -Werror which presumably assumes the default set of warnings used by a certain version of gcc. I think the appropriate solution to this is, as Andrew suggests, to make explicit our preference for that warning rather than relying on the implicit defaults. -- Erik Trimble Java System Support Mailstop: usca22-123 Phone: x17195 Santa Clara, CA Timezone: US/Pacific (GMT-0800) -- Erik Trimble Java System Support Mailstop: usca22-123 Phone: x17195 Santa Clara, CA Timezone: US/Pacific (GMT-0800)
Re: Build portability: enable or disable warnings
On May 19, 2011, at 11:32 AM, Alan Bateman wrote: > David Holmes wrote: >> : >> >>> In contrast, there are basically two Java compilers in general use (javac >>> and ecj) >>> and one is part of OpenJDK. Yet, the Java code does not have -Werror >>> enabled by default and there >>> are a mass of warnings there as a result. >> >> I don't understand the point you are making here. Does javac even have a >> -Werror? The bulk of javac warnings stem from legacy code being compiled >> under newer compilers with new language features - the resulting code is not >> erroneous hence only a warning is issued. >> >> I think comparing C/C++ compiler warnings with javac compiler warnings is >> like comparing apples and elephants. > Yes, javac has -Werror and the build has JAVAC_WARNINGS_FATAL to turn it on. > I just checked my recent build of the jdk7/jdk7 forest and javac emits a > total of 9 warnings (7 are unsafe usages of varargs methods and the other two > are unreachable catch clauses). That isn't a lot but javac doesn't have many > warnings enabled by default. A nice project for someone would be to change > the build to -Werror by default and gradually crank up the warnings listed by > -Xlint. I noticed that some parts of the jdk build do use 'javac -Werror', where it was cleaned up they would turn on this flag. But yes, a great project would be to see if we could get to 'javac -Xlint:all -Werror' someday. We really should... in fact it should be a requirement moving forward that all java code be warning free, and stay that way. Not sure about the hotspot java code. -kto > > -Alan. > >
Re: Build portability: enable or disable warnings
On 05/19/2011 08:00 AM, Kelly O'Hair wrote:
On May 19, 2011, at 11:32 AM, Alan Bateman wrote:
David Holmes wrote:
:
In contrast, there are basically two Java compilers in general use (javac and
ecj)
and one is part of OpenJDK. Yet, the Java code does not have -Werror enabled
by default and there
are a mass of warnings there as a result.
I don't understand the point you are making here. Does javac even have a
-Werror? The bulk of javac warnings stem from legacy code being compiled under
newer compilers with new language features - the resulting code is not
erroneous hence only a warning is issued.
I think comparing C/C++ compiler warnings with javac compiler warnings is like
comparing apples and elephants.
Yes, javac has -Werror and the build has JAVAC_WARNINGS_FATAL to turn it on. I
just checked my recent build of the jdk7/jdk7 forest and javac emits a total of
9 warnings (7 are unsafe usages of varargs methods and the other two are
unreachable catch clauses). That isn't a lot but javac doesn't have many
warnings enabled by default. A nice project for someone would be to change the
build to -Werror by default and gradually crank up the warnings listed by
-Xlint.
I noticed that some parts of the jdk build do use 'javac -Werror', where it was
cleaned up they would turn on this flag.
But yes, a great project would be to see if we could get to 'javac -Xlint:all
-Werror' someday.
We really should... in fact it should be a requirement moving forward that all
java code be warning free, and stay that way.
There's a useful interim milestone which is relatively trivial to do.
If javac -Xlint:all gives warnings, you can go javac -Xlint:all,-xyz to
disable the xyz category of warnings. The specific value of xyz to use
is given at the beginning of the warning message in square brackets. If
you go through and do this, you will have categorized the warnings that
occur, and can work on fixing the categories one at a time -- and
removing the corresponding entry from the -Xlint option. Note also that
sometimes warnings are unavoidable, but individual instances can be
suppressed within the Java code using the @SuppressWarnings("xyz")
annotation. The values for the argument of the @SuppressWarnings
annotation are the same words that you can use for -Xlint and which
occur in the warning messages.
-- Jon
Not sure about the hotspot java code.
-kto
-Alan.
Re: Build portability: enable or disable warnings
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: > > >> 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 believe we also disable problematic > warnings when necessary. By using -Werror when we did update compiler > versions we quickly discovered where the compiler was tightening the > rules and issuing new warnings - then we could determine whether to fix > the code (if practical) or disable the warning. > Indeed. All that's happening here is others are using these newer compilers before the HotSpot developers at Oracle. > > In contrast, there are basically two Java compilers in general use (javac > > and ecj) > > and one is part of OpenJDK. Yet, the Java code does not have -Werror > > enabled by default and there > > are a mass of warnings there as a result. > > I don't understand the point you are making here. Does javac even have a > -Werror? The bulk of javac warnings stem from legacy code being compiled > under newer compilers with new language features - the resulting code is > not erroneous hence only a warning is issued. > 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. 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. > 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
Re: Build portability: enable or disable warnings
On 10:32 Thu 19 May , Alan Bateman wrote: > David Holmes wrote: > > : > > > >> In contrast, there are basically two Java compilers in general use > >> (javac and ecj) > >> and one is part of OpenJDK. Yet, the Java code does not have -Werror > >> enabled by default and there > >> are a mass of warnings there as a result. > > > > I don't understand the point you are making here. Does javac even have > > a -Werror? The bulk of javac warnings stem from legacy code being > > compiled under newer compilers with new language features - the > > resulting code is not erroneous hence only a warning is issued. > > > > I think comparing C/C++ compiler warnings with javac compiler warnings > > is like comparing apples and elephants. > Yes, javac has -Werror and the build has JAVAC_WARNINGS_FATAL to turn it > on. I just checked my recent build of the jdk7/jdk7 forest and javac > emits a total of 9 warnings (7 are unsafe usages of varargs methods and > the other two are unreachable catch clauses). That isn't a lot but javac > doesn't have many warnings enabled by default. A nice project for > someone would be to change the build to -Werror by default and gradually > crank up the warnings listed by -Xlint. > javac is generally a good citizen. I was thinking of jdk code. I have built with JAVAC_MAX_WARNINGS=true on a number of occasions and it's only recently (thanks to a few fixes from myself) that it's actually been able to complete the build, due to some Makefiles turning on Werror separately. I expect with JAVAC_WARNINGS_FATAL as well we wouldn't get past CORBA. I do think having a switch to turn on everything but serial and deprecated warnings would be a more achievable goal, and would help get rid of the remaining 1.5 stuff. > -Alan. > > -- 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
Re: Build portability: enable or disable warnings
On 17:00 Thu 19 May , Kelly O'Hair wrote: > snip... > > But yes, a great project would be to see if we could get to 'javac -Xlint:all > -Werror' someday. > We really should... in fact it should be a requirement moving forward that > all java code be warning free, and stay that way. > Slowly working on it... ;-) > Not sure about the hotspot java code. > I got HotSpot's SA to at least compile without needing -source/-target 1.4. Baby steps... > -kto > > > > > -Alan. > > > > > -- 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
Re: Build portability: enable or disable warnings
Jonathan Gibbons wrote
There's a useful interim milestone which is relatively trivial to
do. If javac -Xlint:all gives warnings, you can go javac
-Xlint:all,-xyz to disable the xyz category of warnings. The specific
value of xyz to use is given at the beginning of the warning message
in square brackets. If you go through and do this, you will have
categorized the warnings that occur, and can work on fixing the
categories one at a time -- and removing the corresponding entry from
the -Xlint option. Note also that sometimes warnings are unavoidable,
but individual instances can be suppressed within the Java code using
the @SuppressWarnings("xyz") annotation. The values for the argument
of the @SuppressWarnings annotation are the same words that you can
use for -Xlint and which occur in the warning messages.
I recently built the jdk7 forest with -Xlint:all,-deprecation and the
number of warnings that javac spat out jumped from 9 to about 3300. I
didn't do a detailed analysis on the warnings except to observe that
about half of them were rawtypes warnings. The second most common one
seemed to be unchecked calls or conversions, and bulk of the others were
redundant casts or missing serialVersionUID. Most of these are easily
fixed, just needs someone to roll up their sleeves and get it done.
Your approach could work but it would be a big step to remove -rawtypes
and -unchecked from the list. Another idea is to start out by enabling
-Xlint:all,-deprecation,-serial so that the 3000+ warnings are laid bare
initially. That would encourage folks to address the warnings, at least
in the areas that they are working on. Once the numbers down to
something manageable then someone could kill off the remaining and turn
on -Werror. I'm sure there many other ways too. The important thing is
that I think we all agree this needs to be done and addressing the javac
warnings is a lot easier than addressing the warnings that we have with
the native code.
-Alan.
Re: Build portability: enable or disable warnings
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: 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. 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 -
Re: Build portability: enable or disable warnings
On 05/19/2011 02:20 PM, David Holmes wrote: javac produces new warnings because new language features cause new potential issues. David, FYI, javac has more warnings than you describe. For example, -Xlint:fallthrough warns about falling from one case in a switch statement into another. That is nothing to do with a new language feature. -- Jon
Re: Build portability: enable or disable warnings
Jonathan Gibbons said the following on 05/20/11 09:39: On 05/19/2011 02:20 PM, David Holmes wrote: javac produces new warnings because new language features cause new potential issues. David, FYI, javac has more warnings than you describe. For example, -Xlint:fallthrough warns about falling from one case in a switch statement into another. That is nothing to do with a new language feature. Ok point taken. I guess javac can also get more picky about what it warns about over time. Thanks, David
Fwd: Heads up, new jaxp source drop
FYI... -kto Begin forwarded message: > From: "Kelly O'Hair" > Date: May 19, 2011 17:53:36 PM GMT+02:00 > To: core-libs-dev > Subject: Heads up, new jaxp source drop > > Heads up. The jdk7/tl forest has a new jaxp source drop dependency. > > 7044493: Incorrectly formated GPL headers in JDK7 JAXP source drop > http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/bdf77cbd9958 > > The new source drop bundle is called: > jaxp145_01.zip > > So if you have your own ALT_DROPS_DIR cache, you need to add this file: > http://download.java.net/jaxp/1.4.5/jaxp145_01.zip > > The changes involve minor source copyright/license corrections only. > > -kto
