怎样才能使AbstractMap.SimpleEntry可变？

Question

How can AbstractMap.SimpleEntry be simultaneously

1) mutable (it's method setValue( ) changes value part of the entry)

2) having equals() / hashCode() defined including value part of the entry

3) be the part of Set<Map.Entry<T,K>> entrySet() result

It seems to me, that these three points are controversial. For example, first two violates contract of Set<> interface, which is not recommending to have mutable elements of the set.

May I be sure, that mutating of Value won't break the map?

Why didn't they did Entry comparable and hashable by key only? This would increase speed in some cases?

Answer 1

I be sure, that mutating of Value won't break the map?

Yes, absolutely. The HashMap buckets take into account only the key portion of the entry:

public V  [More ...] put(K key, V value) {
    if (key == null)
        return putForNullKey(value);
    int hash = hash(key.hashCode()); // <<== HERE
    ...
}

Why didn't they did Entry comparable and hashable by key only? This would increase speed in some cases?

The hashCode and equals of Map.Entry have very little relevance: they would be used only if you wanted to hash entries outside the HashMap itself. The internal implementation of the EntrySet supplied to the callers of Map.entrySet does not use hashCode / equals of the entry - instead, they use the hash code of only the key portion. Here is part of a relevant source code for looking up an object in the entry set:

 public boolean contains(Object o) {
     if (!(o instanceof Map.Entry))
         return false;
     Map.Entry<K,V> e = (Map.Entry<K,V>) o;
     Entry<K,V> candidate = getEntry(e.getKey());
     return candidate != null && candidate.equals(e);
 }

Answer 2

This might be an "opinion" question. Here's my best guess.

I think that Set<Map.Entry<T,K>> is made available so that you can iterate over the elements of the set to get all key/value pairs in a map. However, other operations on this Set would be used rarely. In particular, it seems unlikely that one would use the contains method on this set, which would require building a Map.Entry object of some concrete class that has both a key and a value, to see if it's in this Set<Map.Entry<T,K>> . Since I think contains would be the main use of the hashCode , and since contains would rarely be used, I don't think the hashCode() defined for the Map.Entry is of much use, and thus it shouldn't be a cause for concern. hashCode() is, of course, present because all Object s have them; why they felt a need to define its value formally, I don't know. But I think it's harmless.

Answer 3

There is no contradiction here. The main point that you seem to have missed is that entrySet() does not support adding elements to it .

As such, if a set is well-formed when it is returned by the map, you

1. Cannot create a duplicate in the set, as you cannot change keys or add new entries, hence any two entries will remain different
2. Can change the hash code of an Entry , but cannot influence the hash code of the key, so HashMaps will not break - the bucket of the entry is still the same
3. Cannot change the position of the Entry in a sorted map.

In fact: setValue() does not allow you to change ANYTHING about how the entry is handled by the map, and hence all map contracts will be preserved.

I cannot attest why exactly equals() and hashCode() were implemented in this specific way, maybe the authors of Java had a use case in mind, I don't. (Then again I don't have any use case for those methods in mind at all)

Answer 4

The implementation of AbstractMap.SimpleEntry is to be considered a private implementation detail (its not even used by all Map implementations, eg HashMap doesn't use it).

Note that there is no API that exposes this type directly - its arguable that this class could have been made protected or package private instead of public.

The defining public API is Map.Entry (note that any Map returns a Set). Any implementation of Entry needs to conform to this contract, and the hashCode implementation is clearly defined there.

A class making use of SimpleEntry will need to override part of the definition to handle setValue() if that is needed by its entrySet() implementation (Take a look at HashMap for an example how its handled). The hashCode of Entry, while documented, is not neccessarily used by the implementation of entrySet().

As for "why" is it the way it is: Ask the designer. Conjecture on my part is that there isn't a deeper reason.