On 1/7/2015 2:04 PM, Brian Burkhalter wrote:
On Jan 7, 2015, at 12:08 AM, Andreas Lundblad
<andreas.lundb...@oracle.com <mailto:andreas.lundb...@oracle.com>> wrote:
On Mon, Jan 05, 2015 at 05:43:26PM -0800, Joseph D. Darcy wrote:
Hello,
Getting back to this issue in the new year, taking a closer look at
the existing class-level documentation, I don't really see a
compelling case for an edit this large.
I for one would be content if the bug were closed as "not an issue."
HTH,
-Joe
I originally brought this up when I was trying to create a
Comparator<Number>. In my use case I was fine with rounding and
truncation, so I thougth I could safely use longValue. I was then
surprised when I discovered that the method could basically return
arbitrary long values.
With this in mind, perhaps simply an additional sentence in the
class-level documentation would be in order, so to speak (insert as
penultimate sentence):
“In particular, conversions may not preserve the mathematical ordering
of the numeric values represented by Number instances."
Brian
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.
Cheers,
-Joe
