Bug report: AtomicInteger is converted to a Number when returned from function

[Tal Liron]

My pleasure! Well, not quite pleasure, but am happy to help. :) I have a 
lot of code that needs to run on Nashorn, so it is a good test of what 
breaks.

And perhaps unfortunately, I must use the bleeding edge, because the 
Nashorn released in 8u20 was too broken for Prudence to run.

And yes, of course I will test using the defaults instead of 
"optimistic-types=false".

On 08/29/2014 04:45 PM, Attila Szegedi wrote:
> Yes, this is a bug. It stems from our (new in 8u-dev) optimistic handling of types. Basically, the "x=getAtomic()" line is first compiled with the assumption that whatever getAtomic() returns might be representable as an int. As it happens, AtomicInteger extends Number, and the return value filter will see that it's a number and that its value can indeed be represented as int, so it'll coerce it into a primitive int. We'll have to change the responsible logic to be more strict (e.g. only allow actual primitive wrapper types to be coerced).
>
> In the first case it doesn't happen because we have the assumption that "new " operator always returns an object, so we don't attempt to treat it as an int at all.
>
> Thanks for sticking with us; I know it's no fun getting cut on the bleeding edge… The --optimistic-types=false command line option to Nashorn will turn optimistic types off in case this is blocking you, but I advise that you generally test with them being on (as it's certainly the biggest improvement in the latest Nashorn bits), and we'll keep ironing out the wrinkles.