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

Ashwin Jayaprakash ashwin.jayaprakash at gmail.com
Mon Apr 5 19:33:19 EDT 2010

Hmmm..there are 3 problems here:

1) Map.Entry is implemented by SimpleImmutableEntry and it violates the
Liskov substitution principle. I guess that can be forgiven

2) firstEntry, lastEntry etc keep creating tiny objects for every call. This
is a problem, don't you think?

3) Just because it was documented as "*The only way to obtain a reference to
a map entry is from the iterator of this collection-view. *" should we fit
the code around the docs? Instead of the other way around?

Thanks for replying.


On Mon, Apr 5, 2010 at 4:10 PM, Neal Gafter <neal at gafter.com> wrote:

> 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/56b0a50c/attachment.html>

More information about the Concurrency-interest mailing list