JDK 9 RFR of 8067669: Documentation for methods in Number incomplete regarding too large values.

Andreas Lundblad andreas.lundblad at oracle.com
Thu Jan 8 15:13:56 UTC 2015


> 
> On the matter of writing a Comparator<Number>, the basic problem is
> the Number interface is not strong enough to allow you to write such
> functionality.
> 
> First, the Number type basically only means "convertible to a
> primitive." There are no strict requirements on consistency between
> the different conversion methods and there is not even a requirement
> that calling the same Number method on the same object returns the
> same value (since Numbers are not required to be immutable).
> 
> Even just writing a semantically correct Comparator<Number> for
> Number subclasses in the JDK is nontrivial. Multiple Number
> subclasses (BigInteger and BigDecimal) have values outside of the
> set of values that can be represented with a primitive type.
> 
> So a general Comparator<Number> is not really well-defined.

Right. This is something I discovered in the process. (Feel free to look at how for I got [1].)

Although I was the one who brought it up, I think the whole Comparator<Number> discussion is slightly off topic. I still think that explicitly mentioning rounding and truncation is a bit confusing, as even the JDK implementations resort to other methods.

[1] http://stackoverflow.com/a/4192900/276052



More information about the core-libs-dev mailing list