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

[Joseph D. Darcy]

On 1/7/2015 2:04 PM, Brian Burkhalter wrote:
>
> On Jan 7, 2015, at 12:08 AM, Andreas Lundblad 
> <andreas.lundblad at oracle.com <mailto:andreas.lundblad at 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