Java 铸造：是编译器错了，还是语言规范错了，还是我错了？

Question

我一直在阅读 Java 语言规范，第 3 版，并发现我认为规范和 javac 编译器实现之间存在差异。 Eclipse 编译器中也存在相同的差异。

15.16 部分讨论强制转换表达式。它说如果参数类型无法通过强制转换转换为强制类型转换（第 5.5 节），则应该是编译时错误：

如果操作数的编译时类型可能永远不会根据强制转换规则（第 5.5 节）强制转换为强制转换运算符指定的类型，则这是编译时错误。否则，在运行时，操作数的值会通过强制转换为强制转换运算符指定的类型进行转换（如有必要）。

5.5 部分讨论了转换转换。它给出了允许的转换类型列表。列表中特别缺少的是“拆箱转换，然后是扩大/缩小原始转换”。 但是 javac 编译器（以及 Eclipse 编译器）似乎确实允许这种确切的转换顺序。例如：

long l = (long) Integer.valueOf(45);

... 编译得很好。 （有问题的转换是转换为long；参数是java.lang.Integer 类型，因此转换需要取消装箱到int，然后是扩大的原始转换）。

同样，根据 JLS，它应该不可能从 byte 转换为 char，因为（根据 5.1.4）需要扩大基元转换和缩小基元转换 - 但是，编译器也允许这种转换。

谁能赐教？

编辑： 自从提出这个问题后，我已经向 Oracle 提交了 bug report。他们的回答是，这是“JLS 中的一个小故障”。

Answer 1

我认为你是对的，编译器是对的，而规范是错误的......

这会编译：(Object)45 而这不会：(Long)45

理解编译器行为（包括我正在使用的 Intellij）的唯一方法是修改 Casting Conversion 以与 Assignment Conversion 和 Method Invocation Conversion 一致：

• 拳击转换 (§5.1.7) 可选地，然后加宽 参考转化

• 拆箱转换 (§5.1.8) 可选地后跟一个扩大 原始转换。

加

• 扩大和缩小原始对流

规范确实说过“强制转换比赋值或方法调用转换更具包容性：强制转换可以进行除字符串转换或捕获转换之外的任何允许的转换”

Answer 2

根据我的阅读，从int 到long 的转换是由这个子句允许的：

如果类型相同，则可以通过恒等转换将原始类型的值转换为另一种原始类型，或者通过扩大原始类型转换或缩小原始类型转换。

将int 转换为long 是一种扩展原语转换。

剩下的就是从Integer 到int 的转换，这由最后一个项目符号表示：

拆箱转换

当然，在示例中甚至不需要强制转换为 long。

考虑以下四个定义：

final Integer io = Integer.valueOf(45);
final int i = io;
final long l1 = (long)i;
final long l2 = i;

您认为其中任何一个令人惊讶吗？您的原始示例看起来没有任何不同；它只是省略了中间变量。