A DESCRIPTION OF THE REQUEST :
I would like to have
Collections.SynchronizedCollection, SynchronizedMap and etc. to be public classes.

JUSTIFICATION :
There are many cases when bulk access to data must be synchronized but data are not in only one collection or in wider range. The current API does not specify  on which  customer  synchronized implementations synchronizes. The java.util.concurrent are using for example non-acessible internal fields while java.util. are using 'this' as synchronization  customer .

  You may find it not important - one can wrap in synchronized collection and work with it. The problem is however: the more locks we have to take in sequence the more probable is that in two different threads we do it in different  order what gives deadlock.

  If we complicate example to be class like this:

 class  X
{
     public Map getMapView()
     public Queue getQueueView()
     public void doSomeStuff()
};

and assume that all X operations have to be synchronized on the same lock we need to provide correct wrappers to be returned in getMapView and getQueueView. Standard Collections.synchronizedMap does not allow to specify  customer  to synchronize on ( methods exists but are protected). This is simple to do but needs a lot of typing.

Note, the concept of allowing lock  customer  to be specified in constructor should be applied to all classes which are using locks already, including those in java.util.concurrent, i/o streams and so on.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
This will allow me to reduce number of locks to be taken in sequence and spare a lot of "reinventing the wheel",
ACTUAL -
One needs to rewrite Collections.SynchronizedCollection wrapper classes if wants multiple collections to be synchronized on same  customer .

---------- BEGIN SOURCE ----------
No need of presentation.
---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
Write own wrapper ot Cut&Paste from sources.
Posted Date : 2006-01-12 07:00:56.0

N/A

An interesting intermediate solution would be to allow the
factory methods to take a lock object to synchronize on.
Posted Date : 2006-01-12 07:00:56.0

Doug Lea writes:

"I think the proposed intermediate solution
would satisfy the requested usage, and is pretty easy to do,
and so is worth considering. But not a high priority."
Posted Date : 2006-02-04 01:24:48.0