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