JDK 7 类文件向后兼容 JDK 6
JDK 7 的哪些功能（不包括 invokedynamic，因为 java 不使用它）导致新的类文件版本与 JDK 6 不兼容。这表明所有功能都可以通过生成胶水代码的编译器来实现。例如，switch 语句中的 String 可以使用编译器生成的重复的 ifeq 语句来实现。我希望能够为编译器提供 -source 1.7 -target 1.6 标志，使其与 jre 6 兼容，同时使用 jdk 7 中的项目硬币功能。
Which features of JDK 7 (excluding invokedynamic because it is not used by java) causing a new class file version which is not compliant with JDK 6. It seams that all features could be implemented by compiler generating glue codes. For example String in switch statement could be implemented using repeated ifeq statements generated by the compiler. I want to able to give -source 1.7 -target 1.6 flags to compiler to be compliant with jre 6 and at the same time use project coin features in jdk 7.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我还没有阅读编译器的代码，但是一些新功能显然肯定会对字节码产生影响。
“简化的可变参数方法调用”实际上只是一种警告抑制，但它必须在字节码中留下一些标记，以便客户端代码可以以不同的方式显示警告。
“Try-with-resources”生成的代码可以处理正常异常以及在finally 块期间抛出的第二个异常。使用新的 addSuppressed() 方法。这并不完全是类文件格式的更改，但它显然不适用于早期的虚拟机。
“Multi-catch”还生成与任何以前的编译器生成的字节码略有不同的字节码。异常表中的多个条目现在将指向相同的 catch 主体。
I haven't read the code for the compiler, but some of the new features must obviously have an impact on the bytecode.
"Simplified varargs method invocation" is really just a warning suppression, but it must leave some marker in the bytecode so that client code can display warnings differently.
"Try-with-resources" generates code that can handle a normal exception plus a second exception thrown during the finally block. The extra exception is stored using the new addSuppressed() method. This isn't exactly a class-file format change, but it clearly wouldn't work on earlier VMs.
"Multi-catch" also produces bytecode that's subtly different than any previous compiler could produce. Multiple entries in the exception table will now point to the same catch body.
所以让我确保我理解这一点。您想针对不同的 JRE 运行应用程序中的特定类，然后运行所有其他类？我认为，如果您不想使用不同版本的类的每次使用都启动一个单独的 JVM，那么这在理论上是可能的。这将涉及一定程度的复杂性，相当于在不相交的应用程序中的两个 JVM 之间传递信息。开箱即用的情况下，它不会以这种方式工作，因为 6 中的执行环境不知道项目硬币功能。 IIRC 你不能在 1.4 运行时使用泛型，那么这有什么不同呢？归根结底，这似乎确实不值得，但也许我完全错过了你的观点。
So let me make sure I understand this. You want to run a specific class in your application against a different JRE then all of your other classes? I suppose this could be theoretically possible if on every use of the class that you don't want to use a different version you spin up a separate JVM. This would involve a level of complexity that is equivalent of passing information between two JVMs in disjoint applications. Out of the box it doesn't work this way because the execution environment in 6 would not know about project coin features. IIRC you can't use generics in a 1.4 runtime, so how is this different? At the end of the day it truly does not seem worth it, then again maybe I missed your point entirely.