IsCloseTo matcher should operate on Number rather than Double

[mrpotes]

The IsCloseTo/closeTo matcher should be able to check all numerical types are within the bounds set, rather than just doubles. The implementation already worked if a primitive value was cast to double, but did not work in the case of boxed non-Double numbers, e.g. when trying to check Integer values in a list or map, etc.

[sf105]

Interesting. So the use case is that you have a collection of mixed numbers, some of which are floating point and some not?

[mrpotes]

Actually, IIRC I had a long, and wanted to do a close-to check, but it wouldn't work because number wasn't a double.

[sf105]

In that case, it makes more sense to me to have an ordinal version of close to. It feels odd to do floating point comparisons for int/long.

[mrpotes]

I don't disagree with that as also desirable, but if you consider, for example, a number that is being parsed from JSON, you may not know what the eventual type is going to be (JSON not distinguishing between ordinal and floating point numbers), so it is still useful to have the floating point version deal with Number so that if a JSON field had either 123.456 or 123 in it, it would work regardless.

[sf105]

Good point

[nhojpatrick]

@mrpotes wanting to kick start open pr's, can you rebase from master, as hamcrest-core and hamcrest-library have been refactored a lot and also deprecated, so that everything is just in hamcrest.

[nhojpatrick]

Going to try and kick start hamcrest, so if you want to get it merged, please rebase from the branch v2.3-candidates.
Still trying to understand how has permissions to perform a release.