自 Java5 以来初始化通用集合的方法 +钻石操作员

Question

据我所知，泛型仅在编译时有用。

因此可以声明：

private Set set = new HashSet<String>();

然后，在这个字符串哈希集中，将狗或任何东西添加到该集合中，没有任何问题，因为在运行时没有像数组那样进行任何检查（ArrayStoreException ...）（但是您可能会遇到问题就像使用该集合时的类转换一样...

所以我想说的是，我们通常以这种方式实例化泛型集合：

Set<String> set = new HashSet<String>();

我的问题是，为什么我们要放置 HashSet 的类型，因为只有 HashSet 的引用类型变量真的很重要（我认为）

。意思是，我们可以简单地写：

Set<String> set = new HashSet();

并且它的工作原理完全相同，对吧？ 那么为什么我们通常要在实例化的时候写类型呢？ （这不是强制性的）

---

编辑

我知道用于类型推断的“钻石运算符”，但为什么我们甚至需要它！因为类型推断已经起作用了！

以下代码：

            Set<String> set = new HashSet();
            set.add("Test add a string 1");
            set.add("Test add a string 2");
            for ( String s : set ) {
                    System.out.println(s);
            }

产生输出：

测试添加字符串1 测试添加字符串2

自己测试一下 http://ideone.com/vuiCE

所以现在你谈论类型推断作为 Java7 功能，但它已经是为我工作...

使用java7，我将不得不替换我的

            Set<String> set = new HashSet();

By

            Set<String> set = new HashSet<>();

它仍然是2个额外的字符来完成完全相同的事情，不是吗？ （除非泛型不仅仅是Java7的编译时？我不知道）

Answer 1

它的工作原理完全一样吗？

在运行时：是。

在编译时：否

您的代码会将包含任意对象的集合分配给存储包含字符串的集合的变量，这是不好的，并且会被类型检查员皱起眉头。

当您编写 new HashSet() 时，您正在使用 原始类型。我提到这个问题的含义以及为什么应该避免它：

• 什么是原始类型，为什么我们不应该使用它？

---

一般来说，你可以这样争论：

Set<String> set = new HashSet();

离

HashSet tmp = new HashSet();
...
Set<String> set = tmp;

它不远，反过来又离它不远，

HashSet tmp = new HashSet();
tmp.add(7);
...
Set<String> set = tmp;

它仍然可以编译，但是是有一千个理由不好:)

---

Java 7 允许您编写

Set<String> set = new HashSet<>();

，这会告诉编译器推断 <...> 之间的类型。

有关“钻石运算符”的文档：

• 用于通用实例创建的类型推断（来自 oracle.com）
• 通用类型（来自 oracle.com）
• Java 7：钻石运算符

Answer 2

您最后的建议是类型推断，并且已通过所谓的菱形运算符在 Java 7 中引入：

Set<String> set = new HashSet<>();

所以是的，这可能从一开始就存在。但这是 Java，通常需要几十年的时间才能获得新的语言功能批准（<-- 有点夸张）

Answer 3

尽管 Java 目前删除了泛型类型信息，但他们在设计语言和库时非常小心，以便将来可以添加回完整的泛型类型信息（所谓的具体化）。任何正确编写的通用代码（即没有任何 javac 警告）都将在这种语言更改中幸存下来。在您的示例中，钻石版本是面向未来的；原始版本不是 - 当然它仍然必须编译，但它会在运行时抛出类型转换异常。

然而，这种未来兼容性完全是一种幻想。擦除将永远伴随着我们。如果引入完全具体化，可以肯定地说几乎所有重要的通用代码都会崩溃，因为每个人都在编写不正确通用代码。

这不是我们的错。 Java 迫使我们这样做。它让我们消除了废话，我们别无选择，只能绕过它来实现一些东西。我们的代码充满了对擦除细节知识的依赖。

JDK是最罪孽深重的一个。 JDK API 经过精心设计，可以在具体化中生存；然而，实现取决于擦除。如果Java增加了具体化，这些JDK代码就必须重写。如果 Java 团队指责我们编写了不正确代码，而他们自己却必须做同样的事情，那就太虚伪了。

考虑到大量代码如果不重写就无法在具体化中生存，我们可以有把握地说，只要 Java 保持向后兼容性的承诺，它就永远不会添加具体化。

在这种情况下，是的，无论如何。 Set并没有什么真正可怕的地方。 set = new HashSet()。就我个人而言，我总是添加 <> 以避免警告。 （实际上，只要有可能，我都会尝试使我的代码具有具体化证明，正如我所说，这是一种妄想行为）

在您的示例中，推理是微不足道的。可能存在更复杂的情况，其中 <> 推理并不是那么简单，它的类型检查可能会有所帮助，而原始版本则缺乏这一点。

class Foo<T>
{
    Foo(Class<T> clazz){}
}

Foo<String> foo1 = new Foo(Integer.class);    // compiles (wrongly) 

Foo<String> foo2 = new Foo<>(Integer.class);  // does not compile

Answer 4

Java 7 解决了添加有限类型推断的问题
类实例创建表达式。在需要显式声明参数化类型的情况下
构造函数，以及完整的参数化类型 < T1、T2、...Tn＞的
该构造函数从上下文中显而易见，然后参数化
构造函数的类型可以替换为空类型集
参数：<>。 <>构造时使用构造是合法的
对象并将其分配给变量，或者将其传递为
一个参数。

详细信息：点击此处

Answer 5

其实并不需要。
如果您键入

Set<String> s = new HashSet();

代码进行编译，我们会收到一条警告，我们可以使用 Xlint 检查该警告。

Note: filetest.java uses unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.

然后，如果我们尝试添加一个整数值，例如我们会收到编译错误。