MetricRegistry Key based Lookup

jbee commented 4 years ago

In response to #543 this PR adds methods to MetricRegistry that allow to favour key based lookup over accessing a map first and resolving the target instance from the returned map.

Having to use a map is considered an anti-pattern as in many cases the returned maps are either views or data structures computed on demand. This either taxes implementation complexity (views) or runtime resources (computed maps) unnecessarily and it is somewhat awkward to use as well.

This PR adds to MetricRegistry:

a general key based Metric lookup: Metric getMetric(MetricID metricID);
a generic single type key based lookup: default <T extends Metric> T getMetric(MetricID metricID, Class<T> asType)
implements all existing single type getters as default method of the generic single type lookup method
a name based lookup for Metadata: Metadata getMetadata(String name);
a get or register method for each type that accepts MetricID as key (e.g. counter(MetricID))
implements all existing name and name + tags variants as default methods of the one added accepting MetricID
a get (or null) method for each type that accepts MetricID as key (e.g. getCounter(MetricID))
a multi type filter lookup SortedMap<MetricID, Metric> getMetrics(MetricFilter filter);
a generic single type filter lookup default <T extends Metric> SortedMap<MetricID, T> getMetrics(Class<T> ofType, MetricFilter filter)
implements all existing MetricFilter methods as default methods using the generic single type filter lookup

Notably a Gauge<?> gauge(MetricID metricID, Gauge<?> gauge); method was added that allows to lookup or create a Gauge as an atomic (thread-safe) operation of the registry. No variant with Metadata was added for now.

In addition the existing methods getMetrics() and getMetadata() were marked deprecated.

Tests have been adopted to use the new methods where preferable. This also confirmed that getMetrics() and getMetadata() should not exist. There are no longer used by the TCK.

The same is largely true for methods like getCounters() that were mostly used to do getCounter(MethodID) in form of getCounters().get(MetricID) and so forth.

MetricRegistry has been changed to an interface and default methods have been used to show how the API can benefit from the use without providing implementations for methods that should be implemented based on the internal data organisation. Mapping String name or String name and Tag[] to MetricID can only be done correct in one way. There is no value in duplicating this logic. From an implementation standpoint the same is true for all methods accepting a MetricFilter. As the implementation cannot know the logic of the provided filter there is little room for an implementation to optimise this wherefore it is unlikely that an implementation can do better than the default methods provided. As for the various ways of providing a MetricID the family of methods accepting a MetricFilter is more a convenience feature of the API for the user than an opportunity for an implementation to optimise.