> On 31 Jan 2017, at 14:55, Martin Buchholz <marti...@google.com> wrote: > > > > On Tue, Jan 31, 2017 at 12:32 PM, Paul Sandoz <paul.san...@oracle.com > <mailto:paul.san...@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.