Java 7 钻石运算符：为什么难以实现？答案

【问题标题】：Java 7 diamond operator: why was it difficult to implement?Java 7 钻石运算符：为什么难以实现？
【发布时间】：2012-03-01 07:55:21
【问题描述】：

我观看了 Oracle OTN 虚拟活动：Java SE 和 JavaFX 2.0（2012 年 2 月 28 日），在谈到新的菱形运算符（Map<String, List<String>> myMap = new HashMap<>();）时，演讲者提到它的实现并不像人们想象的那么简单，因为它不是简单的令牌替换。

我的问题是为什么？为什么不能将其实现为简单地从变量声明中获取字符串并将其放入菱形运算符中？

【问题讨论】：

赞成。为什么我们甚至需要一个运算符呢？

标签： java java-7 diamond-operator

【解决方案1】：

我也没有实现，所以只能猜测。

但是通常这些事情比看起来更复杂的原因是第一次检查只查看最常见（或最广为人知的）用例。在这种情况下，它就是您提到的那个。理论上应该很容易准确指定，并且应该很容易在编译器中实现。

但是，菱形运算符（顺便说一下，它在技术上不是运算符）也可以以不同的方式使用：

someMethodWithGenericArguments(new HashMap<>());
new SomeGenericClass(new HashMap<>());
T foo = new SomethingRelatedToT<>(); // where T is a generic type parameter

在这些情况下，简单的标记替换显然不再有效，您需要涉及真实类型分析的实际类型推断（即，它与简单的标记替换处于完全不同的抽象级别）。

【讨论】：

谢谢，我看到这些情况确实更复杂。第一种情况提出了一个问题，如果someMethodWithGenericArguments() 被 ˙Map˙ 和 Map<Integer,Integer>. 重载怎么办。在这种情况下，菱形运算。对我来说似乎完全模棱两可..
@jabal：试试看！由于 Map<String,String> 和 Map<Integer,Integer> 具有相同的擦除 (Map)，因此您不能对单个方法进行这两个覆盖。

【解决方案2】：

Java 没有做的事情（许多语言都有）是基于使用的隐含类型。即 Java 并不意味着基于其使用方式的要求类型。

例如

 Type a = b;

a 的类型和b 的类型是独立的，不会根据a 的类型对b 做任何假设。

MethodHandles 显示出支持这一点的迹象。返回类型的使用可以基于上下文，但这是一个运行时特性。

总之，我的假设是；在 Java 中很难实现，因为该语言不支持任何类似的语言。如果该语言一直使用这样的特性，那么编译器中的工具就会理解所采用的方法（根据定义它应该如何工作的规范）并得到支持。

【讨论】：

奇怪的是，编译器已经支持方法调用的泛型类型参数的类型推断。但对于对象实例化，该功能仅通过 Diamond Operator 添加。