> > 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
