Java HashMap - 是否有必要为每个集合使用.put()？

Question

想象一下以下场景.您有一组已经可访问和已知的值.出于某些原因,您必须将它们放入HashMap中.

代码示例:

String a = "a";
Strinb b = "b";
...
HashMap map = new HashMap(5);
map.put("a", a);
map.put("b", b);
...

真的有必要这样做吗？我无法相信没有一个构造函数可以让你从头开始输入你的值.

我在谈论这样的事情:

HashMap map = new HashMap(<"a", a>, <"b", b>, ...);

甚至是这样的:

HashMap map = new HashMap(5);
HashMap.putBunchOfStuff("a", a, "b", b, ...);

编辑:我的目的是询问是否有方法但更重要的是,如果答案是"否",为什么没有这样的构造函数/方法.

Answer 1

遗憾的是,集合文字是Java 7(和Java 8)中Project Coin的提案,但它从未成为最终产品,也就是说它不是Java的一个特性.

这个命题是这样的

Here’s how it would look with map literals:


    final Map<Integer, String> platonicSolids = { 
          4 : "tetrahedron",
          6 : "cube", 
          8 : "octahedron", 
          12 : "dodecahedron", 
          20 : "icosahedron"
    };


Here is the empty map literal, which has a slightly irregular syntax to make
it differ from the empty set:


    Map<String, Integer> noJokeHere = { : };

但它永远不会发生,所以不幸的是,这不起作用.因此,除非你在Per-ÅkeMinborg这个网站上写自己的魔法建造者或花哨的lambda ,否则你就是独立的.但是,该站点的以下内容应该可以使用(在Java 8中).

//copy paste from linked site
Map<Integer, String> map = Stream.of(
            new SimpleEntry<>(0, "zero"),
            new SimpleEntry<>(1, "one"),
            //...
            new SimpleEntry<>(11, "eleven"),
            new SimpleEntry<>(12, "twelve"))
            .collect(Collectors.toMap((e) -> e.getKey(), (e) -> e.getValue()));

简化版,也来自网站:

//copy paste from linked site
public static <K, V> Map.Entry<K, V> entry(K key, V value) {
    return new AbstractMap.SimpleEntry<>(key, value);
}

public static <K, U> Collector<Map.Entry<K, U>, ?, Map<K, U>> entriesToMap() {
    return Collectors.toMap((e) -> e.getKey(), (e) -> e.getValue());
}

Map<Integer, String> map = Stream.of(
            entry(0, "zero"),
            //...
            entry(12, "twelve"))
            .collect(entriesToMap());

由于以下几点,未引入集合文字:

• 这个功能的"简单"版本(集合,列表,地图)不是很令人满意或很受欢迎; 这个功能的"可扩展"版本是开放式的,凌乱的,几乎可以保证超出其设计预算;

• 基于库的版本为我们提供了1%的成本的X%,其中X >> 1;

• 价值类型即将到来,在价值类型的世界中"这个特征会是什么样子"可能与没有价值类型的世界完全不同,这表明在价值类型之前尝试做这项工作会有问题;

• 我们最好将语言设计带宽集中在更多地解决基于库的版本的基础问题上(包括:更高效的varargs,常量池中的数组常量,不可变数组,以及对缓存(以及压力下的回收)的支持不可变的结果).

来自Oracle的Brian Goetz