先问问题，故事如下：
在类层次结构中混合不同的字节码版本是否安全？有哪些风险？
对于一种情况，C类扩展B，B类扩展A类。A类实现接口I。
我的问题将涉及以下示例场景：
- A 类编译为 Java 1.6 字节码，并具有 1.6 特性，如泛型等。继承人 B 和 C 被编译为 1.4 字节码。
- 接口我编译为1.6，而实现者编译为1.4。
- 其他涉及不同版本字节码的奇异继承场景。
我尝试了尽可能多的场景，似乎运行得很好。不过我还是很想在这里问一下，因为我只了解Java的表面；我知道如何编码和调整 Java，但并不真正知道幕后发生了什么。
现在，对于那些忍不住要问“为什么你需要这样做？？？”的人来说。
我正在参与一个项目，评估旧版 Java 1.4 Swing 应用程序（通过 RMI 连接到 EJB 2）到 Java 1.6 Swing（连接到也在 1.6 之上运行的较新版本的 App Server）的迁移。 J2EE 平台仍为 1.4 (EJB 2)。
迁移不会是“将所有内容重新编译到 1.6”，而是“将新功能编码并编译到 1.6”。
他们做事的方式是这样的：
他们在 CVS 中只有一条路径，每个人都在那里提交。没有任何标签/分支来获取生产代码。
每当需要添加新功能时，他们都会从生产服务器获取 JAR，分解它们，根据需要替换或添加新类，重新打包 jar，然后将它们放回服务器。
因此，如果他们使用Java 6来编译并使用上述方法进行部署，将会出现很多1.4和1.6字节码的奇特混合。
Java 1.0 和 Java 6 之间的 JVM 字节码没有显着差异。在 Java 7 中，它们添加了一条新指令。呜呼。
字节码的工作方式几乎没有变化
- JVM 不支持嵌套类访问外部类的私有成员，这通过生成的代码来实现。
- JVM 不支持泛型的运行时检查，例如您不能
new T()其中 T 是泛型。
基本上，它们使 JVM 更智能、更快，但直到最近，人们还是不惜一切代价避免改变字节码工作方式的模型。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
