JDK-8149509 : Add CopyOnWriteArrayList.snapshot()
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: java.util.concurrent
  • Affected Version: 9
  • Priority: P3
  • Status: Open
  • Resolution: Unresolved
  • OS: generic
  • CPU: generic
  • Submitted: 2016-02-09
  • Updated: 2023-08-29
Related Reports
Relates :  
JDK-8200258 - Improve CopyOnWriteArrayList subList code
Relates :  
JDK-6821196 - CopyOnWriteArrayList/Set should provide snapshot methods
Description
A DESCRIPTION OF THE REQUEST :
A reader of CopyOnWriteArrayList most likely needs to see a consistent view of the list for multiple operations. It'll be nice to have a `snapshot()` method that returns a read only List on the current array.

See David M. Lloyd's suggestion and implementation -- http://cs.oswego.edu/pipermail/concurrency-interest/2009-March/005926.html

CopyOnWriteArraySet can also benefit from a `snapshot()` method.

JUSTIFICATION :
Recently I've seen a couple of questions on stackoverflow.com asking for returning  read only views of an underlying list that may be mutated by the owner. While CopyOnWriteArrayList provides good concurrency protection, it does not provide consistency during access (unless using iterator()). A snapshot() method is going to help a lot of use cases.

[1] http://stackoverflow.com/questions/35287565
Comments
I'm assuming Arrays.unmodifiableArrayList() is like Arrays.asList(), except that all writes to the underlying array are disallowed. If so, sounds reasonable. (Modulo a naming bikeshed, e.g. Arrays.asUnmodifiableList()?). An unmodifiable-snapshot method in COWAL that uses this sounds great. I guess the efficiency gain compared to Collections.unmodifiableList() would be that there wouldn't be a wrapper class. Would there be any other efficiencies? It would be good to have a mutable-snapshot method on COWAL as well, though, since that satisfies a use cases mentioned in JDK-6821196. I'm not sure how much Arrays 2.0 will impact any of this. The general idea is that array.freeze() will return a frozen (immutable) array. If called on a mutable array, it's cloned to a frozen one, which is returned. If called on an already-frozen array, it simply returns it. (Of course, this is all speculative, subject to change in the future, etc.) I can see how frozen arrays would help avoid defensive copying in some cases. But since we have to support the List interface, I think we'd still have to provide the same classes and APIs. If we're careful about how we expose things we might be able to slip in frozen arrays in the future, but I don't think it impacts the API much.
10-02-2016
I keep forgetting about Collections.unmodifiableList(cowal.clone()) But my vision included the most efficient version of this. First, we create maximally efficient Arrays.unmodifiableArrayList and then snapshot() could return an unmodifiableArrayList around the internal array. Maybe Arrays 2.0 has a different vision?
10-02-2016
I've linked JDK-6821196, but I'm not sure if it's a duplicate. There are a couple different things being asked for. One is a mutable snapshot. This can be accomplished functionally via clone(). Unfortunately using clone() requires an unchecked cast. Changing COWAL.clone() to have a covariant override is somewhat risky, as a subclass might have overridden the Object-returning clone(), which leads to infinite recursion with the bridge method when the overriding method calls super(). Also, clone() isn't obvious, though improving its doc might help a bit. Still, adding another method that has specific mutable-snapshot semantics and that has the right return type would be useful. A second request is an unmodifiable snapshot method. Given a mutable-snapshot method, it's not clear that an unmodifiable snapshot method is necessary. It doesn't seem to add much over Collections.unmodifiableList(cowal.snapshot())
10-02-2016
Straightforward and worthwhile but tedious to do, and no one has finished the work (although more than one has started)
10-02-2016