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?
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
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.
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.
class C extends A with B, is implemented with normal interfaces A and B and companion classes A$class and B$class. class C simply forwards the methods to the static companion classes. Self-types are not enforced at all, lambdas are transpiled on compile-time to abstract inner classes, so is a new D with A with B expression. Pattern-matching is a bunch of if-else structures. Non-local returns? try-catch mechanism from the lambda. Anything left? (Interestingly, my scalac says 1.6 is the default) –
Plumbiferous trait A { def foo: Int = 12 } and class C extends A, you roughly get: interface A { int foo(); }, class A$class { public static int foo(A $this) { return 12; } } and class C implements A { public int foo() { return A$class.foo(this); } }. So the default method implementation gets moved to an X$class class, and in each implementing class of the trait, the compiler generates a stub method that just forwards to the method in X$class, giving this as an argument (for if X.foo were to call X.bar). –
Plumbiferous java.util.Function and scala.Function1 are both handled the same, and a => a + 1 can compile to both of them) compilation, using java.lang.invoke.LambdaMetaFactory. –
Plumbiferous -target:jvm-1.7, but I'd have to try out). 2.11 and below? Yeah. (Although I think it's Java 6 and upwards since quite some time, don't know exactly whether that's accurate) –
Plumbiferous If you are willing to use a "retrotranslator" try Esko Luontola's excellent Retrolambda: https://github.com/orfjackal/retrolambda
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
-source 1.7 won't fly. –
Patrizius © 2022 - 2024 — McMap. All rights reserved.