RFR: jsr166 jdk9 integration wave 14

[Paul Sandoz]

> On 31 Jan 2017, at 16:16, Martin Buchholz <martinrb at google.com> wrote:
> 
> 
> 
> On Tue, Jan 31, 2017 at 4:03 PM, Paul Sandoz <paul.sandoz at oracle.com <mailto:paul.sandoz at oracle.com>> wrote:
>> 
>> ConcurrentSkipListSet
>> —
>> 
>>   76  * <p>Bulk operations that add, remove, or examine multiple elements,
>>   77  * such as {@link #addAll}, {@link #removeIf} or {@link #forEach},
>>   78  * are <em>not</em> guaranteed to be performed atomically.
>>   79  * For example, a {@code forEach} traversal concurrent with an {@code
>>   80  * addAll} operation might observe only some of the added elements.
>> 
>> toArray was removed, and it’s not atomic. Same for many other cases.
>> 
>> We tried to maintain complete lists of non-atomic operations, but those became stale as new methods got added to  superclasses/superintterfaces.  Even toString is non-atomic!  Give up or be pedantically exhaustive?
> 
> The removal “toArray” is arguably a specification change, and it’s removal could be misconstrued as implying it is now atomic. So i would just leave the existing documentation as is.
> 
> But ... the problem is that the docs implied that all the other operations *were* guaranteed atomic, which became untrue when y'all added forEach and friends.  That is, this is supposed to be a doc bug fix.  And toString was always missing from the list.
> 

Is not toString a bulk operation that examines multiple elements?

I know toArray fits within that remit, but i just prefer to keep to the original documentation, since the change might be incorrectly perceived as a change in behaviour.

It’s a very mild objection, please override if you feel i am being overly conservative here!

Paul.



>  * Additionally, the bulk operations {@code addAll},
>  * {@code removeAll}, {@code retainAll}, {@code containsAll},
>  * {@code equals}, and {@code toArray} are <em>not</em> guaranteed
>  * to be performed atomically. For example, an iterator operating
> 
>