据本文http://slurp.doc.ic.ac.uk/pubs/observing/linking.html#assignment：
由于Java代码和字节码的信息差异 （字节码不包含局部变量的类型），验证者 不需要检查子类型是否分配给局部变量，或者 到参数。
我的问题：为什么字节码不包含局部变量的类型信息，而它确实包含参数和返回值的类型信息？
【问题讨论】：
compile-time 检查了类型值，导致代码不再需要类型值信息，只需要二进制数据。然而，方法参数和返回值在run-time 调用，并且需要用于类型检查的信息
首先，有几种不同的类型概念。有编译时类型，其中包括泛型。但是，泛型在编译后不存在。
有一个变量的验证推断静态类型，可以是int、float、long、double、returnaddress，或者是一个对象引用。对象引用还带有一个上限，因此所有引用都是 java/lang/String 的子类型。字段还可以具有以下一种短类型：byte、short、char 或 boolean。出于执行目的，它们与 int 相同，但存储不同。
最后是运行时类型，它与验证后的静态类型相同，但在对象引用的情况下，表示被引用实例的实际类型。请注意，由于验证者的惰性，在某些情况下运行时类型实际上可能不是已验证类型的子类型。例如，声明类型为 Comparable 的变量实际上可以保存 Hotspot 中的任何对象，因为 VM 在验证时不会检查接口。
编译时间信息不会保留，除非通过反射和调试的可选属性。这是因为没有理由保留它。
局部变量没有明确的类型信息（新的 StackMapTable 属性除外，但这是技术性的）。相反，当加载类时，字节码验证器通过运行静态数据流分析来推断每个值的类型。这样做的目的不是为了捕捉编译时类型检查之类的错误，因为假设字节码在编译时已经通过了此类检查。
相反，验证的目的是确保指令不会对虚拟机本身造成危险。例如，它需要确保您没有采用整数并将其作为对象引用进行干扰，因为这可能导致任意内存访问和入侵 VM。
因此，虽然字节码值没有显式类型信息，但它们确实具有隐式类型，这是静态类型推断的结果。尽管它们应该遵循 JVM 标准，但其细节会根据每个 VM 的内部实现细节而有所不同。但是您只需要担心手写字节码中的这一点。
字段具有明确的类型，因为 VM 需要知道其中存储了哪种类型的数据。方法参数和返回类型被编码在所谓的方法描述符中，也用于类型检查。它们不可能自动推断，因为这些值可以来自或去任何地方，而类型检查是基于每个类完成的。
附：在谈到验证类型时，我遗漏了一些小细节。对象类型还跟踪它们是否已初始化，如果未初始化，则由哪个指令创建它们。地址类型跟踪创建它们的 jsr 的目标。
【讨论】：
returnAddress 类型仅与 jsr 和 jsr_w 操作码一起使用，它们在 Java 6 中被禁止。现代字节码操作的值永远不会包括returnAddress.
45.0，这样做会在 Hotspot 中启用一些有趣的未记录行为。如果您只考虑 Java 编译的字节码，那么 javac 生成的字节码将永远不会做很多事情。但字节码黑客仍然对它感兴趣。
那是一篇很旧的论文。当前的类文件做包括本地和堆栈变量的类型。类型不存储在方法字节码中，而是存储在附加到方法的StackMapTable attribute 中。
在没有StackMapTable 的情况下，通过数据流分析重建所有局部变量和堆栈元素的类型是（并且一直是）可能的，但它的计算成本很高。带有StackMapTables 的代码可以更快地得到验证。虽然我不得不承认我不知道验证StackMapTables 比进行分析更快，但我对此几乎一无所知。
【讨论】：
StackMapTable 属性。它只是更快，因为数据流不再需要在循环或分支的情况下进行多次传递。
Java bytecode 保留关于 fields 的类型信息，
method returns 和 parameters 但它没有，
如你所愿，
包含local variables 的类型信息。
Java 类文件中的类型信息呈现任务
bytecode 的反编译比反编译的容易
machine code。因此，反编译 Java 字节码需要
大多数局部变量类型的分析，基于堆栈的扁平化
loops 和 conditionals 的指令和结构。
然而，字节码反编译的任务很多
比编译难。你会经常看到反编译器
无法完全发挥其预期功能
【讨论】：