The Java 8 desugaring was extremely efficient, but otherwise adoption was low, performance was worse, and integration with other tooling was non-existent. This was built on the Eclipse Java compiler but emitting Dalvik bytecode instead of Java bytecode. The Android tools team then announced a new compiler which would provide Java 8 language feature desugaring along with better performance. The generated classes were very expensive in terms of method count, but work on the tool over time reduced the cost to something reasonable. This worked by using the built-in mechanism which the JVM uses to turn lambdas into classes at runtime except happening at compile-time. Initially a third-party tool called Retrolambda had to be used.
The goal is always the same: allow newer language features to run on all devices. This history of the Android toolchain’s desugaring capability is… colorful.
Instead, a process named desugaring is used which turns lambdas into representations compatible with all API levels developers are targeting. As the error message indicates, Android’s support for this bytecode requires a minimum API of 26 or newer–something practically unfathomable for applications at the time of writing.
This is because lambdas use a newer bytecode, invokedynamic, added in Java 7. Invalid opcode ba - invokedynamic requires -min-sdk-version >= 26 Uncaught translation error: .cf.code.SimException:ĮRROR in Java8.main:([Ljava/lang/String )V: $ $ANDROID_HOME/build-tools/28.0.2/dx -dex -output. Java8.java Java8.class Java8$Logger.class This brought a more terse expression of code as data whereas previously more verbose constructs like anonymous classes would be used. The banner language feature of Java 8 was by far the addition of lambdas. So let’s start there with a look at how Android’s toolchain deals with the language features of Java 8. When someone talks about Android’s Java 8 support they usually are referring to the language features. There’s a lot to a single version of Java: the language features, the bytecode, the tools, the APIs, the JVM, and more. It’s a complicated topic because what exactly we mean when talking about Android’s Java support can be unclear. At conferences and other developer events it comes up in conversation or in talks with different degrees of accuracy. Every year at Google I/O you could find me asking about it at the fireside chats or directly to the folks responsible. I’ve worked from home for a few years, and during that time I’ve heard people around the office complaining about Android’s varying support for different versions of Java.
0 kommentar(er)
