Broken property access on objects from other contexts?

Hannes Wallnöfer hannes.wallnoefer at oracle.com
Fri Mar 10 14:32:38 UTC 2017


Thanks for the report, Ryan!

I have filed the issue below and I’m working on the fix.

 https://bugs.openjdk.java.net/browse/JDK-8176511

Hannes


> Am 09.03.2017 um 22:10 schrieb Ryan Berdeen <rberdeen at hubspot.com>:
> 
> I'm running into an issue passing plain JS objects to a function created
> with loadWithNewGlobal. I didn't expect property access to behave
> differently on objects from other contexts, but the behavior when using
> numeric keys seems broken.
> 
> Is there a safe way to pass objects between contexts so that the property
> access semantics don't change?
> 
> I wrote a simple test script. It creates a function with a new global that
> is simply o[i] = o[i]. If the key (once converted to a string) exists in o,
> this shouldn't change the value in o.
> 
>    var reassignNewGlobal = loadWithNewGlobal({
>      script: '(function (o, i) { o[i] = o[i]; })',
>      name: 'test.js'
>    });
> 
>    function test(i) {
>      var o = {};
>      o[i] = true;
>      o[i] = o[i];
>      print('expected: ' + JSON.stringify(o));
>      reassignNewGlobal(o, i);
>      print('actual:   ' + JSON.stringify(o));
>      print();
>    }
> 
>    test(-2147483649);
>    test(-2147483648);
>    test(2147483647);
>    test(2147483648);
> 
> Running this, I get
> 
> expected: {"-2147483649":true}
> actual:   {"-2147483649":true,"-1":null}
> 
> expected: {"-2147483648":true}
> actual:   {"-2147483648":null}
> 
> expected: {"2147483647":true}
> actual:   {"2147483647":true}
> 
> expected: {"2147483648":true}
> actual:   {"2147483648":true,"-1":null}
> 
> There are a few strange things here:
> * The issue that broke my actual application, which is that you can't read
> properties with names outside the range of int
> * Setting a property with a name outside the range of int actually sets a
> property named "-1"
> * You can't get properties with negative names, but you can set them
> * When the value is missing due to one of the above, null is returned
> rather than undefined
> 
> Debugging through this, it looked like the logic driving this is
> in JSObjectLinker get/put, but I couldn't tell from there if this behavior
> was intentional or a bug. I would expect keys to be converted to strings
> except when the target is an array, but it instead seems based on whether
> they key is an int or a long.
> 
> I tested tested this with with the Oracle JRE 1.8.0_66-b17 and 9-ea+158.
> 
> Thanks!
> 
> Ryan



More information about the nashorn-dev mailing list