RFR: jsr166 jdk9 integration wave 14
Paul Sandoz
paul.sandoz at oracle.com
Wed Feb 1 15:44:25 UTC 2017
> On 31 Jan 2017, at 16:40, Martin Buchholz <martinrb at google.com> wrote:
>
>
>
> On Tue, Jan 31, 2017 at 4:30 PM, Paul Sandoz <paul.sandoz at oracle.com <mailto:paul.sandoz at oracle.com>> wrote:
>
>> On 31 Jan 2017, at 16:16, Martin Buchholz <martinrb at google.com <mailto: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?
>
>
> 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.
I think that would be too pedantic as well. At this late stage in 9 i prefer to leave things as they are and not fiddle. Revise for 10?
Paul.
More information about the core-libs-dev
mailing list