A DESCRIPTION OF THE REQUEST :
The static method java.util.Collections.synchronizedMap returns a view of a map that provides thread-safe access to all methods defined by the interface java.util.Map.
Since the interface java.util.concurrent.ConcurrentMap was added to the Core libraries, it would make a lot of sense if the synchronized view returned by the method implemented this extended interface.

JUSTIFICATION :
The interface java.util.concurrent.ConcurrentMap offers some handy "atomic modification operations" on maps, e.g. "putIfAbsent".
These methods could be easily implemented by the class that is used as the return type for java.util.Collections.synchronizedMap.


EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
import java.util.*;
import java.util.concurrent.*;
ConcurrentMap map = Collections.synchronizedMap(new TreeMap());
ACTUAL -
import java.util.*;
Map map = Collections.synchronizedMap(new TreeMap());

CUSTOMER SUBMITTED WORKAROUND :
Implement the functionaliy of the "atomic modification operations" from java.util.concurrent.ConcurrentMap manually.
Posted Date : 2005-09-22 10:55:32.0

N/A

An interesting suggestion.

We've tried to avoid having too many cross-package references
from java.util to java.util.concurrent.

Semantically, a concurrent map is different from a synchronized map
in that a synchronized map has a single lock that client code can
build higher-level transactions upon.
Posted Date : 2005-09-22 16:56:42.0

Doug Lea writes:

"This is not a bad idea, but I can't think of a compelling motivation
to carry it out. If people need the operations of ConcurrentMaps, they will
normally just use the ones provided instead of synchronized wrappers."
Posted Date : 2006-02-04 01:09:10.0

The same type of pattern could be applied to the Queue and BlockingQueue but how do you handle the fail-fast Iterators?
How would the synchronizedMap handle the TreeMap Iterators?  I would think changing the Iterators of the synchronizedMap to snapshot views would break compatibility.  So the result will be a ConcurrentMap with fail-fast Iterators, support for null values, and hidden 2x key lookup cost.

>Semantically, a concurrent map is different from a synchronized map
>in that a synchronized map has a single lock that client code can
>build higher-level transactions upon.

I don't see how that would affect the implementation of ConcurrentMap's additional methods. They would use the synchronized map's lock, of course.
IMHO, extending the capabilities of Collections.synchroniziedMap to match those of a ConcurrentMap seem quite natural.
I can see the structural problem, though: this would introduce anthoer "package cycle" into the Core Libraries.
But then again, does one more really make a difference...