[concurrency-interest] Immutable Entry objects in j.u.TreeMap

Doug Lea dl at cs.oswego.edu
Tue Apr 6 10:51:47 EDT 2010

On 04/06/10 07:31, Benedict Elliott Smith wrote:
> Hi - don't think I've posted to this list before now...
> Why would it be a bigger problem to return an "internal" node? All
> internal state is private to the class, so the only accessor a client
> has is the setValue() method which cannot break the integrity of the
> map. Besides which, as mentioned, the "internal" node can be grabbed
> from the entrySet() so if this is a good argument for avoiding returning
> it (which I don't think it is), it is being broken elsewhere anyway.

I agree that the inconsistency here is hard to defend except on
historical grounds (Collection APIs had to accommodate Java 1.1
classes), but the specs for NavigableMap say...

Implementations of entry-returning methods are expected to return Map.Entry 
pairs representing snapshots of mappings at the time they were produced, and 
thus generally do not  support the optional Entry.setValue method. Note however 
that it is possible to change mappings in the associated map using method put.



More information about the Concurrency-interest mailing list