RFR: jsr166 jdk9 integration wave 14
Paul Sandoz
paul.sandoz at oracle.com
Wed Feb 1 00:03:28 UTC 2017
> On 31 Jan 2017, at 14:55, Martin Buchholz <martinrb at google.com> wrote:
>
>
>
> On Tue, Jan 31, 2017 at 12:32 PM, Paul Sandoz <paul.sandoz at oracle.com <mailto:paul.sandoz at oracle.com>> wrote:
>
> 1057 static final VarHandle ITEM;
> 1058 static final VarHandle NEXT;
>
> Suggest a comment as to why they are package private, due to access via a nested class. (Same in LinkedTransferQueue).
>
>
> package private is almost always used for nestmates in j.u.c.; a comment doesn't seem worthwhile.
>
Ok, may i suggest renaming to NODE_ITEM and NODE_NEXT?
>
> 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.
Paul.
More information about the core-libs-dev
mailing list