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.
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.
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.
来源：https://stackoverflow.com/questions/6699347/jdk-7-class-file-backward-compatibility-with-jdk-6