hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tom White (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HADOOP-958) Building Hadoop results in a lot of warnings
Date Mon, 26 Feb 2007 20:29:05 GMT

    [ https://issues.apache.org/jira/browse/HADOOP-958?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12475989
] 

Tom White commented on HADOOP-958:
----------------------------------

On 26/02/07, Nigel Daley <ndaley@yahoo-inc.com> wrote:
> If I remember correctly, -Xlint only shows the first 100 warnings, so
> until our warning count is < 100, this scheme won't work.  Please
> correct me if I'm wrong here.

By default this is true. However, you can use the -Xmaxwarns setting to increase the limit.
I just tried this and I got the following counts for the core code:

-Xlint:unchecked 250
-Xlint:deprecation 256
-Xlint 579 (this includes unchecked and deprecation)

My feeling is that we should tackle unchecked and deprecation warnings. Unchecked are fairly
mechanical - basically replace raw types with parameterized types. Deprecations need handling
on a case-by-case basis, since some things need refactoring to avoid use of deprecated features
(e.g. see deprecated methods in FileSystem).

What do people think the best way to approach this would be? Create a series of patches (by
package)? Do we need patches for the more mechanical changes (e.g. some of the generics changes),
or could committers just do it? Is there a way of minimising the impact on people's patches?

> 
> I like the idea of using @SuppressWarnings annotation where appropriate.


> Building Hadoop results in a lot of warnings
> --------------------------------------------
>
>                 Key: HADOOP-958
>                 URL: https://issues.apache.org/jira/browse/HADOOP-958
>             Project: Hadoop
>          Issue Type: Improvement
>            Reporter: eric baldeschwieler
>
> We are getting hundreds of warnings right now.  Most of these are a result of our transition
to 1.5 and deprecated uses of generics.  We should still fix these, since producing lots of
warnings:
> A) Leads to the perception that our code is of low quality
> B) Can mask warnings that come from real issues.
> ---
> I suggest we do two things
> 1) Submit a patch or set of patches to clean this up
> 2) Change our patch tester to validate that the number of warnings per build did not
go up with this patch

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message