Can Java 8 code be compiled to run on Java 7 JVM?

JavaJvmCompatibilityJava 7Java 8

Java Problem Overview


Java 8 introduces important new language features such as lambda expressions.

Are these changes in the language accompanied by such significant changes in the compiled bytecode that would prevent it from being run on a Java 7 virtual machine without using some retrotranslator?

Java Solutions


Solution 1 - Java

No, using 1.8 features in your source code requires you to target a 1.8 VM. I just tried the new Java 8 release and tried compiling with -target 1.7 -source 1.8, and the compiler refuses:

$ javac Test -source 1.8 -target 1.7
javac: source release 1.8 requires target release 1.8

Solution 2 - Java

Default methods require such changes to the bytecode and the JVM that they would have been impossible to do on Java 7. The bytecode verifier of Java 7 and below will reject interfaces with method bodies (except for the static initializer method). Trying to emulate default methods with static methods on the caller side would not produce the same results, because default methods can be overridden in subclasses. Retrolambda has limited support for backporting default methods, but it can never be fully backported because it truly requires new JVM features.

Lambdas could run on Java 7 as-is, if the necessary API classes just would exist there. The invokedynamic instruction exists on Java 7, but it would have been possible to implement lambdas so that it generates the lambda classes at compile time (early JDK 8 builds did it that way) in which case it would work on any Java version. (Oracle decided to use invokedynamic for lambdas for future proofing; maybe one day JVM will have first-class functions, so then invokedynamic can be changed to use them instead of generating a class for every lambda, thus improving performance.) What Retrolambda does is that it processes all those invokedynamic instructions and replaces them with anonymous classes; the same as what Java 8 does at runtime when a lamdba invokedynamic is called the first time.

Repeating Annotations is just syntactic sugar. They are bytecode compatible with previous versions. In Java 7 you would just need to implement yourself the helper methods (e.g. getAnnotationsByType) which hide the implementation detail of a container annotation which contains the repeated annotations.

AFAIK, Type Annotations only exist at compile time, so they should not require bytecode changes, so just changing the bytecode version number of the Java 8-compiled classes should be enough to make them work on Java 7.

Method parameter names exist in the bytecode with Java 7, so that's also compatible. You can get access to them by reading the bytecode of the method and looking at the local variable names in the method's debug information. For example the Spring Framework does exactly that to implement @PathVariable, so there is probably a library method which you could call. Because abstract interface methods don't have a method body, that debug information doesn't exist for interface methods in Java 7, and AFAIK neither on Java 8.

The other new features are mostly new APIs, improvements to HotSpot and tooling. Some of the new APIs are available as 3rd party libraries (e.g. ThreeTen-Backport and streamsupport).

Summa summarum, default methods require new JVM features but the other language features don't. If you want to use them, you'll need to compile the code in Java 8 and then transform the bytecode with Retrolambda to Java 5/6/7 format. At minimum the bytecode version needs to be changed, and javac disallows -source 1.8 -target 1.7 so a retrotranslator is required.

Solution 3 - Java

As far as I know none of these changes in JDK 8 required the addition of new bytecodes. Part of the lambda instrumentation is being done using invokeDynamic (which already exist in JDK 7). So, from the JVM instruction set standpoint, nothing should make the codebase incompatible. There are, though, a lot of API associated and compiler improvements that would could make the code from JDK 8 difficult to compile/run under previous JDKs (but I have not tried this).

Maybe the following reference material can help somehow to enrich the understanding of how the changes related to lambda are being instrumented.

These explain in detail how things are instrumented under hood. Perhaps you can find the answer to your questions there.

Solution 4 - Java

If you are willing to use a "retrotranslator" try Esko Luontola's excellent Retrolambda: https://github.com/orfjackal/retrolambda

Solution 5 - Java

You can do -source 1.7 -target 1.7 then it will compile. But it won't compile if you have java 8 specific features like lambdas

Attributions

All content for this solution is sourced from the original question on Stackoverflow.

The content on this page is licensed under the Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) license.

Content TypeOriginal AuthorOriginal Content on Stackoverflow
QuestionNicola AmbrosettiView Question on Stackoverflow
Solution 1 - JavaJesperEView Answer on Stackoverflow
Solution 2 - JavaEsko LuontolaView Answer on Stackoverflow
Solution 3 - JavaEdwin DalorzoView Answer on Stackoverflow
Solution 4 - JavaStefan ZobelView Answer on Stackoverflow
Solution 5 - JavakalgecinView Answer on Stackoverflow