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.
