RFR: jsr166 jdk9 integration wave 14

Martin Buchholz martinrb at google.com
Wed Feb 1 00:40:26 UTC 2017


On Tue, Jan 31, 2017 at 4:30 PM, Paul Sandoz <paul.sandoz at oracle.com> wrote:

>
> 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>
> 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?
>
>
Yes!


> 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.
>
>
I'm trying to expand the list of non-atomic methods without exhaustively
listing all its members.


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

Would having exhaustive lists of methods make you happier?  That would be
more precise, but too pedantic for my taste.


More information about the core-libs-dev mailing list