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

[Sundararajan Athijegannathan]

As discussed offline, please leave Nashorn Parser API changes for a 
separate issue.

-Sundar

On 1/11/2016 8:07 PM, Hannes Wallnoefer wrote:
> 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
>>>
>>
>