RFR: 8196340: (coll) Examine overriding inherited methods in ArrayList and ArrayList.SubList (original) (raw)

Ivan Gerasimov ivan.gerasimov at oracle.com
Mon May 14 20:29:36 UTC 2018

Thank you Claes!

The mutator methods normally first update the modCount and then change the size of ArrayList.

Then, in other methods the modCount is copied to a local variable first, and after that the size is copied.

This is not true for equalsRange(List<?> other, int from, int to) when it is called from ArrayList.equals: the size is first copied to the argument and then the modCount is checked inside of equalsRange(). If the size and modCount are changed in between, then equals may produce a wrong results.

It seems to be more accurate to store this.modCount prior calling to equalsRange((List<?>) o, 0, size); and do checkForComodification(expectedModCount); after it is done.

Checking for modCount inside equalsRange() can probably be safely removed.

There's another call to equalsRange() from SubList.equals(). In this case checkForComodification(); is already called after calling to equalsRange(), so everything seems to be fine here.

With kind regards,

Ivan

On 5/14/18 6:37 AM, Claes Redestad wrote: > Hi Ivan, >> right, checkForComodification() alone should be sufficient here. >> Updated in-place: http://cr.openjdk.java.net/~redestad/8196340/open.01/ >> Thanks! >> /Claes >> On 2018-05-12 03:38, Ivan Gerasimov wrote: >> Hi Claes! >>>> One thing I can't figure out is why both these two checks are necessary: >>>> 1303 checkForComodification(); >> 1304 root.checkForComodification(expectedModCount); >>>> The former compares the current root.modCount with the one at the >> time this subList was created. >>>> The later one compares the current root.modCount with the one at the >> time the method was called. >>>> If the later fails, wouldn't it imply the former should also have >> failed? >>>>>> With kind regards, >>>> Ivan >

With kind regards, Ivan Gerasimov

More information about the core-libs-dev mailing list