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

[Sundararajan Athijegannathan]

Looks good!

-Sundar

On 1/12/2016 3:03 PM, Hannes Wallnoefer wrote:
> I uploaded a new webrev without the changes to the parser API.
>
> http://cr.openjdk.java.net/~hannesw/8143896/webrev.03/
>
> Note that parserapi.js.EXPECTED changes because of the changes in 
> parserapi.js, which is itself included in the files it parses.
>
> Please review.
>
> Hannes
>
> Am 2016-01-11 um 16:57 schrieb 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
>>>>>
>>>>
>>>
>>
>