So instead of com.codahale.metrics the 4.0.0 release will use the io.dropwizard.metrics package name.
Apart from the obvious backward incompatibility, the most challenging aspect of this change is that the Maven dependency will only see a version incrementation. This means that you won’t be able to include both versions in the same Maven module, because the groupId and the artifactId will not change between the 3.x.x and the 4.x.x version change.
This change is manageable in an end-user application as you only have to migrate from one version to the other. An open source framework built on top of Dropwizard Metrics is much more difficult to refactor as you need to support two incompatible versions of the same library. After all, you don’t want to force your clients to migrate to a certain Metrics dependency.
Luckily, FlexyPool has had its own Metrics abstraction layer from the very beginning. Insulating a framework from external dependencies is a safety measure, allowing you to swap dependencies without much effort.
To support both Codahale and Dropwizard package names, FlexyPool metrics are build like this:
Because those classes cannot reside in one jar, there are three modules hosting this hierarchy:
flexy-pool-core: defines the FlexyPool Metrics abstraction
flexy-codahale-metrics: implements the FlexyPool metrics abstraction on top of Codahale Matrics
flexy-dropwizard-metrics: implements the FlexyPool metrics abstraction on top of Dropwizard Matrics
This way FlexyPool can use both Metrics implementations and the decision is taken dynamically based on the currently available library. The Dropwizard metrics 4.0.0 is not yet released, but FlexyPool is ready for the upcoming changes.