Java 7钻石运营商:为什么难以实施?

时间:2012-03-01 07:55:21

标签: java java-7 diamond-operator

我观看了Oracle OTN虚拟事件:Java SE和JavaFX 2。0(2012年2月28日),在谈到新的钻石操作员(Map<String, List<String>> myMap = new HashMap<>();事件)时,发言人提到它并不像一个人那么简单。可能会想,因为它不是一个简单的代币替换。

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

2 个答案:

答案 0 :(得分:14)

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

通常这些事情比看起来更复杂的原因是第一次检查只关注最常见(或最公开)的用例。在这种情况下,它是你提到的那个。从理论上讲,它应该很容易准确指定,并且应该很容易在编译器中实现。

然而,钻石操作员(顺便说一下,在技术上不是操作员)也可以以不同的方式使用:

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

在这些情况下,简单的令牌替换显然不再有效,您需要涉及实际类型分析的实际类型推断(即,它将在完全不同的抽象级别上作为简单的令牌替换)。

答案 1 :(得分:2)

Java没有做的事情(许多语言都有)是基于用法的隐含类型。即Java并不暗示基于其使用方式的require类型。

e.g。

 Type a = b;

a的类型和b的类型是独立的,并且不会根据b的类型对a进行任何假设。

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

总之,我的假设是;在Java中很难实现,因为语言不支持任何类似的语言。如果所使用的语言一直都是这样的特征,那么可以理解采用的方法(在定义它应该如何工作的规范方面)并且由编译器中的工具支持。