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 object synchronized implementations synchronizes. The java.util.concurrent are using for example non-acessible internal fields while java.util. are using 'this' as synchronization object.

  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 object 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 object 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 object.

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

CUSTOMER SUBMITTED WORKAROUND :
Write own wrapper ot Cut&Paste from sources.