为什么 Map.of 不允许空键和值？

Question

在 Java 9 中，为List 、 Set和Map接口引入了新的工厂方法。 这些方法允许使用一行中的值快速实例化 Map 对象。 现在，如果我们考虑：

Map<Integer, String> map1 = new HashMap<Integer, String>(Map.of(1, "value1", 2, "value2", 3, "value3"));
map1.put(4, null);

以上是允许的，没有任何例外，而如果我们这样做：

Map<Integer, String> map2 = Map.of(1, "value1", 2, "value2", 3, "value3", 4, null );

它抛出：

Exception in thread "main" java.lang.NullPointerException
    at java.base/java.util.Objects.requireNonNull(Objects.java:221)
..

我无法得到，为什么在第二种情况下不允许 null 。

我知道 HashMap 可以将 null 作为键和值，但为什么在 Map.of 的情况下会受到限制？

同样的事情发生在java.util.Set.of("v1", "v2", null)和java.util.List.of("v1", "v2", null) 。

Answer 1

正如其他人指出的那样， Map合约允许拒绝空值......

[S] 某些实现禁止null键和值 [...]。 尝试插入不合格的键或值会引发未经检查的异常，通常为NullPointerException或ClassCastException 。

...和收集工厂（不仅仅是在地图上） 利用了那个。

它们不允许null键和值。 尝试使用null键或值创建它们会导致NullPointerException 。

但为什么？

在集合中允许null现在被视为设计错误。 这有多种原因。 一个好的是可用性，其中最突出的麻烦制造者是Map::get 。 如果它返回null ，则不清楚是缺少键还是值为null 。 一般来说，保证null集合更容易使用。 在实现方面，它们还需要较少的特殊外壳，使代码更易于维护和性能更高。

你可以听 Stuart Marks在这个演讲中解释它，但JEP 269 （介绍工厂方法的那个）也总结了它：

将不允许使用空元素、键和值。 （最近引入的集合都没有支持空值。）此外，禁止空值为更紧凑的内部表示、更快的访问和更少的特殊情况提供了机会。

由于HashMap在慢慢被发现时已经被广泛使用，因此在不破坏现有代码的情况下对其进行更改为时已晚，但是这些接口的最新实现（例如ConcurrentHashMap ）不再允许null并且工厂方法的新集合是也不例外。

（我认为另一个原因是显式使用null值被视为可能的实现错误，但我错了。这将复制密钥，这也是非法的。）

所以禁止null有一些技术原因，但这样做也是为了使用创建的集合提高代码的健壮性。

Answer 2

确切地说 - HashMap允许存储 null，而不是静态工厂方法返回的Map 。 并非所有地图都相同。

一般来说，据我所知，首先允许HashMap空值作为键是错误的，较新的集合禁止这种可能性开始。

想想你的HashMap中有一个条目，它有一个特定的键和值 == 空的情况。 你确实得到了，它返回null 。 这是什么意思？ 它有一个null映射还是不存在？

Key ——来自这样一个空密钥的哈希码必须一直被特殊处理。 禁止空值开始 - 让这更容易。

Answer 3

虽然 HashMap 确实允许空值，但Map.of不使用HashMap并且如果将其中一个用作键或值，则会引发异常，如 文档所示：

Map.of() 和 Map.ofEntries() 静态工厂方法提供了一种创建不可变映射的便捷方法。 这些方法创建的 Map 实例具有以下特点：

• ...

• 它们不允许空键和值。 尝试使用空键或值创建它们会导致 NullPointerException。

Answer 4

在我看来，不可空性对键有意义，但对值则不然。

1. Map接口变成了一个弱契约，你不能在不查看实现的情况下相信它的行为，那就是假设你有权查看它。 Java11 的Map.of()不允许空值，而HashMap允许，但它们都实现了相同的Map契约 - 为什么？
2. 有一个空值或根本没有值是不可能的，并且可以说不应该被视为一个不同的场景。 当你得到一个键的值并且你得到空值时，谁在乎它是否明确地放在那里？ 提供的键根本没有值，地图不包含这样的键，就这么简单。 Null 为 null，没有 nullnull 或 null^2
3. 现有的库广泛使用 map 作为向它们传递属性的一种手段，其中许多是可选的，这使得Map.of()作为此类结构的构造毫无用处。
4. Kotlin 在编译时强制执行可空性，并允许使用没有已知问题的空值映射。
5. 不允许空值背后的原因可能只是由于创建者的实现细节和便利性。

Answer 5

主要区别在于：当您以“选项 1”的方式构建自己的 Map 时……那么您就含蓄地说：“我希望在我正在做的事情上拥有完全的自由”。

因此，当您决定您的地图应该有一个空键或值（可能是出于此处列出的原因）时，您可以自由地这样做。

但是“选项 2”是关于方便的事情 - 可能旨在用于常量。 Java 背后的人简单地决定：“当你使用这些方便的方法时，结果映射应该是空的”。

允许空值意味着

 if (map.contains(key)) 

不一样

 if (map.get(key) != null)

有时这可能是一个问题。 或者更准确地说：这是在处理那个地图对象时要记住的事情。

这只是一个轶事提示，为什么这似乎是一种合理的方法：我们的团队自己实现了类似的便利方法。 猜猜看：在对未来 Java 标准方法的计划一无所知的情况下 - 我们的方法做完全相同的事情：它们返回传入数据的不可变副本； 当您提供 null 元素时，它们会抛出。 我们甚至非常严格，当您传入空列表/地图/...时，我们也会抱怨。

Answer 6

在地图中允许空值是一个错误。 我们现在可以看到它，但我想不清楚什么时候引入HashMap 。 NullpointerException是生产代码中最常见的错误。

我会说 JDK 朝着帮助开发人员对抗 NPE 瘟疫的方向发展。 一些例子：

• Optional介绍
• Collectors.toMap(keyMapper, valueMapper)不允许keyMapper和valueMapper函数返回null值
• 如果找到的值为null Stream.findFirst()和Stream.findAny()将抛出 NPE

所以，我认为在新的 JDK9 不可变集合（和映射）中禁止null朝着相同的方向发展。

Answer 7

文档没有说明为什么不允许使用null ：

它们不允许null键和值。 尝试使用null键或值创建它们会导致NullPointerException 。

在我看来，将Map.of()和Map.ofEntries()静态工厂方法主要由编译类型的开发人员形成。 那么，保留null作为键或值的原因是什么？

而Map#put通常用于在运行时填充可能出现null键/值的映射。

Answer 8

并非所有 Map 都允许 null 作为键

docs of Map提到的原因。

一些地图实现对它们可能包含的键和值有限制。 例如，有些实现禁止空键和值，有些实现对其键的类型有限制。 尝试插入不合格的键或值会引发未经检查的异常，通常为 NullPointerException 或 ClassCastException。