为什么Java 7钻石运算符不能与匿名类一起使用?

Dav*_*oll 36 java diamond-operator java-7

考虑这个尝试实例化某些Lists的Java代码:

List<String> list1 = new ArrayList<String>();
List<String> list2 = new ArrayList<>();
List<String> list3 = new ArrayList<String>() { };
List<String> list4 = new ArrayList<>() { };
List<String> list5 = new ArrayList<Integer>() { };
Run Code Online (Sandbox Code Playgroud)

list1并且list2很简单; list2在Java 7中使用新的菱形运算符来减少不必要的类型参数重复.

list3list1使用匿名类的变体,可能会覆盖一些方法ArrayList.

list4尝试使用菱形运算符,类似于list2,但这是一个编译错误,消息'<>'不能与匿名类一起使用.

list5产生一个错误,证明编译器知道实际需要什么类型.错误消息是类型不匹配:无法从新的ArrayList <Integer>(){}转换为List <String>

那么,随着声明list4,为什么钻石运算符不能用于匿名类?这里有一个类似的问题,接受的答案包含JSR-334的以下解释:

不支持使用带有匿名内部类的菱形,因为这样做通常需要扩展类文件签名属性以表示不可表示的类型,事实上的JVM更改.

我需要一些帮助来理解推理.为什么显式类型与相同且明显容易推断的类型需要在生成的类文件中有任何差异?"一般这样做"会涵盖哪些难以处理的用例?

这是什么原因?

ass*_*ias 21

在"项目硬币"邮件列表中进行了讨论.实质上(强调我的):

在内部,Java编译器在一组更丰富的类型上运行,而不是那些可以在Java程序中显式写下的类型.无法在Java程序中编写的编译器内部类型称为不可表示的类型.由于钻石使用的推断,可以出现不可表示的类型.因此,不支持使用具有匿名内部类的菱形,因为这样做通常需要扩展类文件签名属性以表示不可表示的类型,事实上的JVM更改.只要推断类型是可表示的,在创建匿名内部类时,未来平台版本可以允许使用菱形是可行的.

请注意,它在Java 8中也不受支持,但将作为Java 9中的新功能("Milling Project Coin"的第3项)包含在内.

  • 非常感谢这个答案.您链接的邮件列表也指向http://bugs.java.com/bugdatabase/view_bug.do?bug_id=6894753,其中包含更深入的分析以及"困难"类的示例.简而言之,似乎推断不适用于匿名类的原因是支持它的工作将是不成比例的. (2认同)
  • JDK 9 的解决方案正如人们想象的一样简单:只允许它用于可表示的类型。最大的讽刺是,他们想要避免的问题已经存在。考虑 `public class Foo&lt;T&gt; { Foo(T t) {} public static void main(String... arg) { System.out.println( new Foo&lt;&gt;("".getClass()).new Inner( ) {} .getClass().getGenericSuperclass()); } 类内部 {} }`。这捕获了无法用字节码表达的不可表示类型。在 JDK 11 之前,它会产生无效的字节码,从 JDK 11 开始,它会产生编译器错误“非法签名属性”且没有任何解释。 (2认同)