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

[Hannes Wallnoefer]

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
>>>>
>>>
>>
>