Java-8 – why doesn’t map extend functions?

While using the new Java 8 stream API, I want to know why not:

public interface Map<K,V> extends Function<K,V>

even to the extent that:

public interface Map<K,V>,Predicate<K>

It is quite easy to use the default method on the map interface:

@Override default boolean test(K k) {
    return containsKey(k);
}

@Override default V apply(K k) {
    return get(k);
}

And it will allow the use of maps in the map method:

final MyMagicMap<String,Integer> map = new MyMagicHashMap<>();
map.put("A",1);
map.put("B",2);
map.put("C",3);
map.put("D",4);

final Stream<String> strings = Arrays.stream(new String[]{"A","B","C","D"});
final Stream<Integer> remapped = strings.map(map);

Or as a predicate in a filter method

I found that a large part of my map use case is that construct or similar - as a remapping / lookup function

So why didn't the JDK designer decide to add this feature to the map during the redesign for Java 8?

Solution

Of course, the JDK team knows Java util. Map as data structure and Java util. function. The mathematical relationship between functions is used as the mapping function After all, function was named mapper in the early JDK 8 prototype builds And the stream operation that calls the function on each stream element is called stream map.

Someone might even stream Map is renamed something like transformation, because there may be confusion between transformation function and map data structure (sorry, we can't find the link.) The proposal was rejected on the grounds of conceptual similarities

The main problem is that if Java util. Map is Java util. function. What will you get from the subtype of function? Comments has some discussion about whether subtypes mean "is - a" relationships Subtypes are not "is-a" relationships about objects - because we're talking about interfaces, not classes - but they mean substitutability So if map is a subtype of function, you can do this:

Map<K,V> m = ... ;
source.stream().map(m).collect(...);

We'll face the current function right away Apply to the behavior of existing map methods Maybe the only reasonable thing is map Get, if the key does not exist, null is returned These semantics are frankly a bad language Real applications may write their own methods and provide key missing strategies, so there seems to be no benefit to write

map(m)

replace

map(m::get)

or

map(x -> m.getOrDefault(x,def))