Well, here's an unexpected initial result.
I just ran a build of langtools+jdk on my ubuntu laptop. I got a
whopping 2658 warnings!! [Those who volunteered to help get rid of
all the warnings, don't all step back at once!] But surprisingly,
after a quick "sort -u", only 625 of them are unique. So that means we
get on average a 4x bang for the buck for each warning we fix :-)
-- Jon
On Jul 11, 2008, at 11:02 AM, Jonathan Gibbons wrote:
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
