Yeah I commented on this in the previous PR and I'm not sure how to handle it. The problem here is that it's impossible to guarantee not breaking old applications here as it's completely possible that an existing application makes creates an `AtomicLong`, passes it to `makeCounter` and then just start incrementing the atomic. This would obviously break as we could just use the current atomic value as a starting point for the new counter.

You mention another concern about the thread-safety below which is also unresolvable with the current implementation (without really hurting performance with a synchronized block).

I was thinking about a different approach: Revert all changes to the `Counter` implementation and keep all methods in `StatsCollection` untouched, except the deprecation annotations. Instead, we make a new `LongAdderCounter` implementation that is constructed when `increment()` is invoked. `Counter` instances are returned from various methods in `StatsCollection`, though, so it would have to be turned into a trait which would mean a) some implementations would be thread safe and others not, b) the performance of them would be slightly impacted and c) I'm not sure if changing a class to a trait actually would be binary compatible. Bottom line is that I don't think this is a good approach either.

finagle-stats's traits are exactly in line with what I'm trying to achieve here. Is there a stand-alone library for those abstractions, or is that only available in twitter-server? Trying to find a new path with less resistance...