JDK-4335520 : Provide access to Collections.synchronizedXXX(..., Object lock) variant
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: java.util:collections
  • Affected Version: 6
  • Priority: P5
  • Status: Closed
  • Resolution: Won't Fix
  • Submitted: 2000-05-03
  • Updated: 2020-04-30
  • Resolved: 2020-04-30
Related Reports
Duplicate :  
Description
Name: skT45625			Date: 05/03/2000


java version "1.2.2"
Classic VM (build JDK-1.2.2-001, native threads, nojit)

I would like to see the following methods added to the java.util.Collections
utility class:

public static Collection synchronizedCollection(Collection c, Object lock);
public static List synchronizedList(List l, Object lock);
public static Set synchronizedSet(Set s, Object lock);
public static Map synchronizedMap(Map m, Object lock);
public static SortedSet synchronizedSortedSet(SortedSet ss, Object lock);
public static SortedMap synchronizedSortedMap(SortedMap sm, Object lock);

Each of these methods would return a wrapper around the given collection which
synchronizes all access on the given lock object (which must not be null). This
would allow more flexibility than the current versions of these methods. In
particular, it would be possible for a bean to expose a List (or Set, or Map,
etc.) view of some internal data that is synchronized on the bean itself,
instead of the wrapper. For example:

public class Wombat {
    private List internalList = ..;

    public List getInternalList() {
        // the returned list is synchronized on the wombat that owns it
        return Collections.synchronizedList(internalList, this);
    }
}

NOTE: The implementation for these methods is already in place so providing
these methods should be fairly simple.
(Review ID: 104421) 
======================================================================

Comments
Recent discussion in this area on core-libs-dev: http://mail.openjdk.java.net/pipermail/core-libs-dev/2020-April/066123.html The suggestion here is to expose a "getSyncRoot()" method that exposes the internal mutex that view collections of synchronized wrappers use for locking. This is necessary to do proper external synchronization on view collections. Unfortunately, it breaks encapsulation by allowing access to the backing collection. The need for external locking of synchronized collections is somewhat mitigated by the addition of various default methods that do bulk operations under a lock, for example, forEach(), removeIf(), and replaceAll(). Fundamentally, the problem with the mailing list proposal and the proposal here (adding explicit lock parameters to the factory methods) is that they perpetuate an external synchronization model, which is an architectural dead end. Concurrent data structures are better supported by the classes in java.util.concurrent. Closing as Won't Fix.
30-04-2020

CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: mustang
08-09-2004

WORK AROUND Name: skT45625 Date: 05/03/2000 Implement your own. Not a difficult chore, but its annoying (Especially given that a perfectly good implementation exists but its inaccessible) ======================================================================
08-09-2004

EVALUATION When we initially provided the synchronized wrappers, we considered exporting the requested functionality, but decided to wait and see if there was any demand for the facility. joshua.bloch@Eng 2000-05-04 I now believe there is sufficient demand. ###@###.### 2002-04-26
04-05-2000