[
https://issues.apache.org/jira/browse/HADOOP-7266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14966693#comment-14966693
]
Tsuyoshi Ozawa commented on HADOOP-7266:
----------------------------------------
{quote}
I don't think it's good idea to commit a patch that adds warnings and then
commit another patch that fixes the warnings. I'd like to keep the source code
clean in any revision.
{quote}
I think we cannot say it's clean code by fixing warnings with SuppressWarning
annotation, unfortunately :-( It's just a workaround to make a illusion of
clean code.
{quote}
If we are to add warnings in this issue, we will
* deprecate metrics1 and then remove metrics1 in trunk
* deprecate metrics1 and then fix javac warnings in branch-2
{quote}
To make the code clean in this case, we need to replace them with metrics v2
code. For instance, MetricsServles shoulld be moved under metrics 2 directory
and HttpServer2 code should use it. Do you mean we should do this on this
issue? It sounds good, but the patch is not enough.
I also thought some projects use metrics v1. They need grace period to replace
them - some libraries, like Guava, removes useless methods after annotating
@Deprecated during a limited time. This is a good mark not only for us, but
also for users. This policy is good culture of Guava and we can imitate it.
Thoughts?
http://docs.guava-libraries.googlecode.com/git/javadoc/com/google/common/io/InputSupplier.html
> Deprecate metrics v1
> --------------------
>
> Key: HADOOP-7266
> URL: https://issues.apache.org/jira/browse/HADOOP-7266
> Project: Hadoop Common
> Issue Type: Improvement
> Components: metrics
> Affects Versions: 2.8.0
> Reporter: Luke Lu
> Assignee: Akira AJISAKA
> Priority: Blocker
> Attachments: HADOOP-7266-remove.001.patch, HADOOP-7266.001.patch,
> HADOOP-7266.002.patch, HADOOP-7266.003.patch, HADOOP-7266.004.patch,
> HADOOP-7266.005.patch
>
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
