问题
Java 8引入了重要的新语言功能，例如lambda表达式。
语言中的这些更改是否伴随着编译的字节码中的这些重大更改，这些更改会阻止它在不使用某些反向转换器的情况下在Java 7虚拟机上运行？
#1 热门回答(119 赞)
不，在源代码中使用1.8功能需要你定位1.8 VM。我刚刚尝试了新的Java 8版本并尝试使用-target 1.7 -source 1.8进行编译，编译器拒绝：
$ javac Test -source 1.8 -target 1.7
javac: source release 1.8 requires target release 1.8
#2 热门回答(52 赞)
默认方法需要对字节码和JVM进行此类更改，而这些更改在Java 7中是不可能的.Java 7及更低版本的字节码验证程序将拒绝具有方法体的接口(静态初始化方法除外)。尝试在调用者端使用静态方法模拟默认方法不会产生相同的结果，因为可以在子类中重写默认方法.Retrolambda对后向默认方法的支持有限，但它永远不能完全向后移植，因为它确实需要新的JVM功能。
如果必要的API类存在那里，Lambdas可以按原样在Java 7上运行。 invokedynamic指令存在于Java 7上，但它可以实现lambdas，以便它在编译时生成lambda类(早期的JDK 8版本就是这样做的)，在这种情况下它可以在任何Java版本上运行。 (Oracle决定使用invokedynamic for lambdas进行未来验证;也许有一天JVM将具有一流的功能，因此可以更改invokedynamic以使用它们而不是为每个lambda生成一个类，从而提高性能。)Retrolambda所做的是它处理所有这些invokedynamic指令并用匿名类替换它们;与第一次调用lamdba invokedynamic时Java 8在运行时所做的相同。
Repeating Annotations只是语法糖。它们与先前版本的字节码兼容。在Java 7中，你只需要自己实现帮助器方法(例如，getAnnotationsByType)，该方法隐藏包含重复注释的容器注释的实现细节。
AFAIK，Type Annotations仅在编译时存在，因此它们不应该要求更改字节码，因此只需更改Java 8编译类的字节码版本号就足以使它们在Java 7上运行。
Method parameter names在Java 7的字节码中存在，因此它也兼容。你可以通过读取方法的字节码并查看方法的调试信息中的局部变量名来访问它们。例如，Spring Framework正是为了实现@PathVariable，所以可能有一个库方法可以调用。由于抽象接口方法没有方法体，因此Java 7中的接口方法不存在调试信息，Java 8上也不存在AFAIK。
The other new features主要是新的API，HotSpot和工具的改进。一些新的API可用作第三方库(例如，ThreeTen-Backport和4889752203)。
Summa summarum，默认方法需要新的JVM功能，但其他语言功能则不需要。如果要使用它们，则需要在Java 8中编译代码，然后将字节码转换为Retrolambda到Java 5/6/7格式。至少需要更改字节码版本，并且javac disallows-source 1.8 -target 1.7需要一个逆向转换器。
#3 热门回答(31 赞)
据我所知，JDK 8中的这些更改都不需要添加新的字节码。 lambda仪器的一部分正在使用invokeDynamic(已经存在于JDK 7中)完成。因此，从JVM指令集的角度来看，没有任何东西可以使代码库不兼容。但是，有许多API相关和编译器改进可能会使JDK 8中的代码难以在以前的JDK下编译/运行(但我还没有尝试过)。
也许以下参考资料可以帮助以某种方式丰富对与lambda相关的变化如何被检测的理解。
- 从Lambdas到Bytecode
- Lambda表达式的翻译
这些详细解释了如何在引擎盖下进行检测。也许你可以在那里找到问题的答案。