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.
I like the idea of using @SuppressWarnings annotation where appropriate.
On Feb 26, 2007, at 12:55 AM, Tom White (JIRA) wrote:
[ https://issues.apache.org/jira/browse/HADOOP-958?
page=com.atlassian.jira.plugin.system.issuetabpanels:comment-
tabpanel#action_12475840 ]
Tom White commented on HADOOP-958:
----------------------------------
I saw it the other way round - put in some measures to make sure
number of warnings did not increase with the patch, then tackle the
old warnings. I think it would be quite demoralising to submit
patches that clean up warnings while other patches were being
applied that inadvertantly increased the warning count.
Regarding the manual intervention, we can mitigate this to some
extent by using the SuppressWarnings annotation. Alternatively, we
could make the change in the warning count as an advisory message,
so committers can use their discretion about applying patches.
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.
