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

Neal Gafter neal at gafter.com
Mon Apr 5 19:10:10 EDT 2010


On Mon, Apr 5, 2010 at 3:47 PM, Ashwin Jayaprakash <
ashwin.jayaprakash at gmail.com> wrote:

> I was looking at the JDK 6 java.util.TreeMap source code to see if any of
> the xxEntry methods were returning actual Entry objects or immutable
> snapshots like in j.u.c.ConcurrentSkipMap. I see that the return values in
> TreeMap are confusing. I hope someone here can throw some light on this:
>
> java.util.TreeMap:
>
> 1) entrySet, headMap, tailMap - seem to return Map.Entry references that
> are still referred to by the map. There's no confusion here.
>
> 2) firstEntry, lastEntry, lowerEntry, floorEntry...ceilingEntry - these
> wrap the actual Map.Entry objects with exportEntry(). So, these are actually
> returning AbstractMap.SimpleImmutableEntry instances. Why the difference?
> Why isn't setValue(xx) not allowed on these entries?


The documentation for Map.Entry sheds some light on this, even though
Entry's documentation isn't correct.  Apparently Map.Entry objects are only
supposed to be valid for the duration of that one iteration, but firstEntry,
lastEntry, lowerEntry, floorEntry, and ceilingEntry aren't associated with
an iteration.

I mentioned that the documentation for Map.Entry isn't correct.  I quote:

A map entry (key-value pair). The Map.entrySet method returns a
collection-view of the map, whose elements are of this class. The *only* way
to obtain a reference to a map entry is from the iterator of this
collection-view.

Clearly, methods like firstEntry et al violate this.

Cheers,
Neal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20100405/22f1a4c4/attachment.html>


More information about the Concurrency-interest mailing list