Enable Gauge builders to take a subclass of Number

[s-ste]

This is an idea to make the various Gauge.builder(..) methods more flexible. Currently, due to Java's type erasure, if you want to instantiate a gauge using a Supplier<Integer>, you need to cast this to a Supplier<Number>, weakening your type safety.

You can extend the signature in a backward-compatible way and allow usage, as demonstrated in the tests I've added. I tried fitting the tests into appropriate places, but if this isn't where they should be, I'd be happy to move/refactor them.

I tried to look into issues and PRs to see if something similar had been proposed before, but I couldn't find anything, so I thought of sharing an idea as a PR. In any case, if you believe this is not useful for the project, please reject the PR.

[pivotal-cla]

@s-ste Please sign the Contributor License Agreement!

Click here to manually synchronize the status of this Pull Request.

See the FAQ for frequently asked questions.

[pivotal-cla]

@s-ste Thank you for signing the Contributor License Agreement!

[jonatan-ivanov]

Right now, as a workaround, can you turn this:

Supplier<Long> supplier = () -> 42L;
Gauge.builder("test", supplier).register(registry);

into this?

Supplier<Long> supplier = () -> 42L;
Gauge.builder("test", supplier::get).register(registry);

[shakuzen]

Thank you for the pull request.
I can't think of a reason to not do this, but I'm also not sure the situation in which a reference to a Supplier will be passed to a Gauge builder in real world code. I would imagine typically a method reference or lambda will be used, which avoids the issue. I looked at usage in our code - outside of test code, most is in MicrometerMetricsPublisherThreadPool where method references and lambdas are used with methods that return various types: Number, long, Integer.
That said, as long as it is backward compatible, this makes things nicer for certain usage, so I'm fine doing this. We'll wait until we branch for 1.15 development to merge.

[s-ste]

@jonatan-ivanov Yes, that's right, and you'll still need to fall back to that way for some, e.g (because IntSupplier doesn't extend the same Supplier<T> interface):

IntSupplier supplier = () -> 42;
Gauge.builder("test", supplier::getAsInt).register(registry);

@shakuzen My main use case is to support wrapping the metric registration in an agnostic interface. That keeps my dependencies separated and my business code isn't aware of micrometer. In my case, that interface also makes testing nicer. Hope that description helps and thanks for the really quick response.

interface MetricRegistration {
  void register(String id, Supplier<Long> valueSupplier);
}

[shakuzen]

@s-ste thanks for the explanation. That helps bring some clarity about use cases.

In my case, that interface also makes testing nicer.

Let us know if there's something about testing with Micrometer that's more difficult than it could/should be.

[s-ste]

Thanks for the question. All in all, I love how testable Micrometer is, which makes working with it easy. For multi-module projects, I prefer testing business logic that provides metrics without having Micrometer on the classpath. So, from my side, I just appreciate the great work you do and have nothing to complain about. 😄