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. Thanks, Attila. On Aug 26, 2014, at 8:06 PM, Tal Liron <[email protected]> wrote: > The bug is on trunk in http://hg.openjdk.java.net/jdk8u/jdk8u-dev/nashorn. > > In the following program, the first part works as expected. However, in the > second part, it will fail at "x.incrementAndGet()" because "x" is not an > AtomicInteger instance. > > My guess is that the same bug may affect other Atomic* classes. > > > > x = new java.util.concurrent.atomic.AtomicInteger() > x.incrementAndGet() > print(x + '\n') > > function getAtomic() { > return new java.util.concurrent.atomic.AtomicInteger() > } > > x = getAtomic() > x.incrementAndGet() > print(x + '\n') >
