【发布时间】:2020-12-19 02:30:50
【问题描述】:
Java SE 11 的JLS §5.2 包含了一些Java 8 的JLS 所没有的新类型转换案例,见列表中的第4 项和第5 项:
分配上下文允许使用以下之一:
- 身份转换
- 一个扩大的基元转换
- 扩大参考转换
- 扩大参考转换,然后进行拆箱转换
- 扩展引用转换,然后是拆箱转换,然后是扩展基元转换
- 拳击转换
- 装箱转换,然后是扩大的参考转换
- 拆箱转换
- 拆箱转换,然后是扩大的基元转换
我不明白列表中的case 4和case 5。谁能用例子给我一些解释?如果可能的话,还请解释一下它的实际用法。
更新:
作为@Naman commented,这里是更改 JLS 的建议 - JDK-8166326 : 5.2: Allow widening before unboxing,它自 Java-9 起生效。报告中提到:
此行为对于与捕获的互操作性尤为重要:各种现有程序希望能够将
List<? extends Integer>的元素视为整数。List<? extends Integer> li = null; int i = li.get(0);
这可能暗示这个 JLS 的改变确实有实际的必要性。但是我还是不明白为什么 extends Integer> 很重要。 与捕获的互操作性是什么意思?为什么它很重要?这些现有的各种程序是什么样的?它们是 Java 代码吗(我知道其他一些语言也可以在 JVM 上运行,并且可能与 Java 代码有交互)?
【问题讨论】:
-
@GiorgiTsiklauri 例如,如果有人可以
public class MyBoolean extends Boolean { ... },那么boolean bool = myBoolean;工作是合乎逻辑的。但是由于我们不能从包装器扩展,我不明白我们如何才能进入需要首先扩大引用(从包装器的子类型)然后拆箱的情况。 -
@GiorgiTsiklauri 我想到的唯一可能性是使用 PowerMock 之类的工具来模拟(其中一个)包装器......
-
这里是更改 JLS 的建议 - JDK-8166326 : 5.2: Allow widening before unboxing,自 Java-9 起生效。
-
@Hulk 鉴于编译器确实已经这样做了,因此无需为此寻找实际用例。确保规范和实际的编译器行为一致,已经足以推动这种改变。
标签: java type-conversion java-11 autoboxing jls