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

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