Java 强制转换运算符是如何工作的？

Question

我正在尝试调试涉及 Java 中的 ClassCastException 的问题。为了解决这个问题，我需要知道当我从 Object 转换为特定类型时发生了什么。 谁能向我解释一下 Java cast 运算符在 Java 级别和 JVM 级别是如何工作的？

Answer 1

JLS 够好吗？

强制转换应用于强制转换运算符的操作数（第 15.16 节）：操作数表达式的类型必须转换为强制强制转换运算符显式命名的类型。强制转换上下文允许使用：

• 身份转换 (§5.1.1)
• 一个扩大的基元转换（§5.1.2）
• 一个缩小的原始转换（§5.1.3）
• 一个扩大的参考转换（§5.1.5）可选地后跟一个未经检查的转换（§5.1.9）
• 缩小参考转换 (§5.1.6) 可选地后跟未经检查的转换
• 拳击转换 (§5.1.7)
• 拆箱转换 (§5.1.8)。

其实，也许this part 更相关：

编译时引用类型S的值到编译时引用类型T的强制转换的编译时合法性详细规则如下：

• 如果 S 是一个类类型：
  • 如果 T 是 一个类类型，然后是 |S| <:>T|，或|T| S|;否则是编译时 发生错误。此外，如果有 存在一个超类型 X T 和一个超类型 Y S，使得 X 和 Y 可证明是不同的 参数化类型（§4.5）， 并且 X 的擦除和 Y 都是一样的，编译时 发生错误。
  • 如果 T 是接口类型：
    • 如果 S 不是final 类（§8.1.1）， 那么，如果存在超类型 T 的 X 和一个超类型 S 的 Y，使得两者 X 和 Y 是可证明的 不同的参数化类型，并且 X 和 Y 的擦除 是一样的，编译时错误 发生。否则，演员表总是 在编译时合法（因为即使 S 没有实现 T， S 的子类可能）。
    • 如果 S 是 final 类（§8.1.1）， 那么S必须实现T， 或发生编译时错误。

  • 如果 T 是一个类型变量，那么这个 递归应用算法， 使用 T 的上限 T 的位置。
  • 如果 T 是 数组类型，则 S 必须是 班级Object，或 发生编译时错误。
• 如果 S 是 接口类型：
  • 如果 T 是 数组类型，则 T 必须 实现 S 或编译时 发生错误。
  • 如果 T 是不属于 final (§8.1.1), 那么如果存在超类型 T 的 X 和一个超类型 S 的 Y，使得两者 X 和 Y 是可证明的 不同的参数化类型，并且 X 和 Y 的擦除 是一样的，编译时错误 发生。否则，演员表总是 在编译时合法（因为即使 T 没有实现 S， T 的子类可能）。
  • 如果 T 是 final 的类型， 然后：
    • 如果 S 不是参数化的 类型或原始类型，则 T 必须 实现S，演员表是 静态已知是正确的，或 发生编译时错误。
    • 否则， S 是参数化的 调用某些类型的类型 泛型类型声明 G，或 对应于泛型的原始类型 类型声明 G。然后那里 必须存在一个超类型 X T，使得 X 是 G 的调用，或 发生编译时错误。 此外，如果 S 和 X 可证明是不同的参数化 类型然后编译时错误 发生。
• 如果 S 是 一个类型变量，然后这个算法 递归地应用，使用 S 的上限代替 S。
• 如果 S 是数组类型SC[]， 也就是说，一组组件 键入 SC:
  • 如果 T 是 类类型，那么如果 T 不是 Object，然后是 发生编译时错误（因为 Object 是唯一的类 可以分配数组的类型）。
  • 如果 T 是接口类型，然后是 除非发生编译时错误 T 是类型 java.io.Serializable 或 类型Cloneable， 仅由数组实现的接口。
  • 如果 T 是一个类型变量，那么：
    • 如果上 T 的边界是 Object 或类型 java.io.Serializable 或 Cloneable 类型，或 S 可以的类型变量 合法地被递归地强制转换为 应用这些规则，那么演员表是 合法（尽管未经检查）。
    • 如果上 T 的边界是数组类型 TC[]，然后是编译时错误 除非类型 SC[] 可以 通过递归转换为 TC[] 这些编译时的应用 投射规则。
    • 否则，一个 发生编译时错误。
  • 如果 T 是 一个数组类型TC[]，即一个 TC 类型的组件数组， 然后发生编译时错误 除非以下情况之一为真：
  • TC 和 SC 是 相同的原始类型。
  • TC 和 SC 是引用类型和类型 SC 可以通过以下方式转换为 TC 这些的递归应用 转换的编译时规则。

现在完全清楚了，不是吗？ :D

换句话说，这是我在不了解您的问题的更多细节的情况下能做的最好的事情。

Answer 2

类转换神秘的一个可能原因是不仅类型必须匹配，而且它们必须由同一个类加载器加载。

您不仅应该能够转储类型层次结构，还应该能够转储每个类的类加载器的标识。

这类问题在应用程序代码和基础设施代码被故意隔离的 appserver 风格的环境中并不少见 - 例如，如果系统类意外包含在应用程序 JAR 中，您可以在 JVM 中拥有两个“相同”类的副本，并且生活变得混乱

Answer 3

强制转换断言对象的运行时类型与给定的静态类型兼容，因此允许您在对象上调用该类型的方法。

这里的 obj 是一个 Integer 对象，但只能通过 Object 引用访问：

Object obj = new Integer(1);

铸造让您再次将其视为整数（或整数的某些超类）：

System.out.println(((Integer) obj).intValue());

当给定的静态类型与对象的运行时类型不匹配时发生ClassCastException：

System.out.println(((Float) obj).intValue()); // runtime error

您可以使用 getClass() 和各种 Class 方法找到任何对象的运行时类型：

System.out.println(obj.getClass()); // prints "class java.lang.Integer"

Answer 4

在 Java 虚拟机规范中可以找到其他有用且权威的参考资料，特别是 §2.6.5, "Narrowing Reference Conversions",，尤其是 checkcast 指令的定义。