Review request for JDK-8068872: Nashorn JSON.parse drops numeric keys

[Hannes Wallnoefer]

Yes, test262 and octane run fine.

One pecularity I found is that ensure(newIndex) usually only needs to be 
called if newIndex >= length. But this is not true for SparseArray, as 
newIndex may be smaller than the sparse array's length but still greater 
than the underlying dense array's length/capacity. SparseArray handles 
this by calling its ensure method in various places where other 
ArrayData classes don't.

Now that I think of it I will add a comment about this to 
SparseArray.ensure.

Hannes

Am 2015-02-05 um 10:55 schrieb Attila Szegedi:
> +1, looks good. Array handling can have sensitive corner cases - I presume you've run octane and test262 on this? Will also be curious about Marcus' review (he dealt a lot with arrays in the past).
>
> On Feb 5, 2015, at 10:48 AM, Hannes Wallnoefer <hannes.wallnoefer at oracle.com> wrote:
>
>> Please review JDK-8068872: Nashorn JSON.parse drops numeric keys:
>>
>> http://cr.openjdk.java.net/~hannesw/8068872/
>>
>> The main issue here was that ArrayData.ensure should only update the length if the new index is greater or equal to the old length.
>>
>> I also fixed two other related issues:
>>
>> - ScriptObject.defineProperty(int, Object) must call doesNotHaveEnsureDelete (which marks new unused slots as deleted) after having called ensure.
>> - There's no need to call ensure(length - 1) on a newly created ArrayData(length). I've removed two such cases.
>>
>> Thanks,
>> Hannes