Why Doesn't Java Map Extend Collection

Why doesn't Java Map extend Collection?

From the Java Collections API Design FAQ:

Why doesn't Map extend Collection?

This was by design. We feel that
mappings are not collections and
collections are not mappings. Thus, it
makes little sense for Map to extend
the Collection interface (or vice
versa).

If a Map is a Collection, what are the
elements? The only reasonable answer
is "Key-value pairs", but this
provides a very limited (and not
particularly useful) Map abstraction.
You can't ask what value a given key
maps to, nor can you delete the entry
for a given key without knowing what
value it maps to.

Collection could be made to extend
Map, but this raises the question:
what are the keys? There's no really
satisfactory answer, and forcing one
leads to an unnatural interface.

Maps can be viewed as Collections (of
keys, values, or pairs), and this fact
is reflected in the three "Collection
view operations" on Maps (keySet,
entrySet, and values). While it is, in
principle, possible to view a List as
a Map mapping indices to elements,
this has the nasty property that
deleting an element from the List
changes the Key associated with every
element before the deleted element.
That's why we don't have a map view
operation on Lists.

Update: I think the quote answers most of the questions. It's worth stressing the part about a collection of entries not being a particularly useful abstraction. For example:

Set<Map.Entry<String,String>>

would allow:

set.add(entry("hello", "world"));
set.add(entry("hello", "world 2"));

(assuming an entry() method that creates a Map.Entry instance)

Maps require unique keys so this would violate this. Or if you impose unique keys on a Set of entries, it's not really a Set in the general sense. It's a Set with further restrictions.

Arguably you could say the equals()/hashCode() relationship for Map.Entry was purely on the key but even that has issues. More importantly, does it really add any value? You may find this abstraction breaks down once you start looking at the corner cases.

It's worth noting that the HashSet is actually implemented as a HashMap, not the other way around. This is purely an implementation detail but is interesting nonetheless.

The main reason for entrySet() to exist is to simplify traversal so you don't have to traverse the keys and then do a lookup of the key. Don't take it as prima facie evidence that a Map should be a Set of entries (imho).

Why does Map not extend Collection interface

Collection assume elements of one value. Map assumes entries of key/value pairs. They could have been engineered to re-use the same common interface however some methods they implement are incompatible e.g.

Collection.remove(Object) - removes an element.
Map.remove(Object) - removes by key, not by entry.

You could model a Map as a collection of entries, which is what Map.entrySet() does.

There are some methods in common; size(), isEmpty(), clear(), putAll/addAll() but these are unlikely to have much value as a stand alone interface. (Again Map.entrySet() can be used instead)

Does Map interface extend or implement some other interface or class?

Related question:
Why doesn't Java Map extend Collection?

Map does not extend any interfaces; it is defined as its own interface.

In Java, interfaces don't extend classes, only other interfaces. Technically, all objects in Java extend Object, so any object implementing an interface is an Object.

Java collection not have Map as part of collection framework

Maps work with key/value pairs, while the other collections work with just values. Map maps keys to values. It allows its content to be viewed as a set of keys, a collection of values and a set of key-value mappings.

Check this following link. Answer by oracle.
https://docs.oracle.com/javase/tutorial/collections/

Why is a Map not a true collection?

Map is not a true Collection because it doesn't extend the Collection interface. Besides that, it is a collection by concept.

why not Map#removeAll(Collection?)?

The philosophy behind the collections APIs is to be as small and simple as possible. The Collection views on Map allow you to perform this operation already, so there is no need for an extra method.

The keySet method returns a view of the Map. Operations on the key set are reflected on the map.

The more general question on interface design: Why doesn't interface X have convenient method Y? is addressed in more depth by Martin Fowler's discussion of MinimalInterface vs HumaneInterface.

Why doesn't a Java method with argument Collection? extends V accept SetV?

It's not that you can't use a Set<V> where a method expects a Collection<? extends V>, it's that Map<K, Set<V>> is not a subtype of Map<K, Collection<V>>.

What would work is if you changed your method to accept Map<K, ? extends Collection<V>>.

The reason for this is discussed in many other StackOverflowQuestions, including Is List<Dog> a subclass of List<Animal>? Why aren't Java's generics implicitly polymorphic? . (In the analogy, Dog is Set<V> and Animal is Collection<V>.)

---

Related Topics