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.
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.
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
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?