Review request for JDK-8143896: java.lang.Long is implicitly converted to double

[Hannes Wallnoefer]

I fixed a bug with converstion to number for the strict equality 
operator, which also revealed some left over usage of long in Nashorn 
internals. New webrev is here:

http://cr.openjdk.java.net/~hannesw/8143896/webrev.02/

Hannes

Am 2016-01-11 um 13:48 schrieb Hannes Wallnoefer:
> You are right of course, there needs to be consistency between typeof 
> operator and treatment as JS numbers.
>
> This is in fact an unpleasant problem to solve. I've struggled trying 
> to fix this without breaking any existing code, but I've come to the 
> conclusion that it is not possible. Since we can't treat all Java 
> longs/Longs as JS numbers, we'd have to differentiate depending on 
> whether the value can be represented as double without losing precision.
>
> In a way we already do this with optimistic types, but I consider it 
> more a bug than a feature. It's weird (and error prone) if the return 
> value for a Java method returning long is reported as number or object 
> depending on the actual value.
>
> So I think the right thing to do is draw a clear line between which 
> Java primitive/wrapper types represent JS numbers and which don't. 
> I've uploaded a new webrev that implements this:
>
> http://cr.openjdk.java.net/~hannesw/8143896/webrev.01/
>
> Note that the only types to be treated as JS numbers are the direct 
> wrapper classes for Java primitives that can be fully represented as 
> doubles. This means also things like AtomicInteger and DoubleAdder 
> will be reported and treated as objects. I think that's the correct 
> thing to do as they are not primitive numbers in the first place. They 
> are still converted to numbers when used in such a context in JS. So I 
> think the only place where this change is a actually 
> painful/surprising is longs.
>
> Unfortunately the check for number type in JSType.isNumber gets a bit 
> long as we have to individually check for all primitive wrapper 
> classes. I've done extensive benchmarking and I don't think it has an 
> impact on performance. In any way, I wouldn't know how to handle this 
> differently.
>
> Let me know what you think.
>
> Hannes
>
> Am 2016-01-04 um 05:00 schrieb Sundararajan Athijegannathan:
>> I think I already commented on this webrev -- that we need to cover 
>> tests for BigInteger, BigDecimal.
>>
>> Also, I'm not sure linking Double and Int by nashorn  primitive 
>> linkers is the right solution. AtomicInteger, DoubleAdder etc. are 
>> all Number subtypes. We return "number" when typeof is used on any 
>> Number subtype.
>> Now, that means JS code will see these as 'number' type objects -- 
>> yet Number.prototype methods won't work on those!! I know this is 
>> hard problem -- we also have another (somewhat related) BigDecimal, 
>> BigInteger toString / String conversion issue. We need to discuss this.
>>
>> -Sundar
>>
>> On 1/2/2016 8:29 PM, Attila Szegedi wrote:
>>> +1
>>>
>>>> On Dec 18, 2015, at 3:54 PM, Hannes Wallnoefer 
>>>> <hannes.wallnoefer at oracle.com> wrote:
>>>>
>>>> Please review JDK-8143896: java.lang.Long is implicitly converted 
>>>> to double
>>>>
>>>> http://cr.openjdk.java.net/~hannesw/8143896/webrev/
>>>>
>>>> Thanks,
>>>> Hannes
>>
>