Since libcore (which contains implementation of java.*) and ART are developed in AOSP, we can peek and see that work is already underway towards supporting Java 9. A new process API, var handles, a version of the Reactive Streams interfaces, and collection factories are just some of those which were added. The APIs of Java 9, though, are not yet included in the Android SDK. Those are all the language features of Java 9 and they all already work on Android. Despite being a feature added in Java 9, ART allows private interface members since API 24! If you add a main method which calls hey() and push this to a device it will actually work. We can see that the getHey() method’s access flags still contain both PRIVATE and STATIC. $ $ANDROID_HOME/build-tools/28.0.2/dexdump -d xĬlass descriptor : 'LJava9PrivateInterface 'Īccess flags : 0x0600 (INTERFACE ABSTRACT)Ġ0047c: | Java9PrivateInterface.getHey:()Ljava/lang/String Ġ0048c: 1a00 2c00 |0000: const-string v0, "hey" As such, this release allows you to omit declaring a new variable if you already have an effectively-final reference. But if you already have a Closeable, defining a new variable is redundant. Prior to this release the try-with-resources construct required that you define a local variable (such as try (Closeable bar = foo.bar())). Instead, this release focused on cleaning up some of the sharp edges on existing features. None of them are major like lambdas were. The last release on the 2 - 3 year schedule, Java 9 contains a few new language features. But is it actually the case that we’re stuck with those of Java 8? Let’s take a look at the Java releases beyond 8 and see how the Android toolchain fares. With Java releases happening more frequently, Android’s yearly release schedule and delayed uptake of newer language features and APIs feels more painful. I was hoping for that reaction because I mostly wrote that post so that I could set up this one. The rest of the Java ecosystem is starting to move to Java 11 (being the first long-term supported release after 8) after having toyed with Java 9 and 10.
There’s a future promise for the APIs which is essential for the health of the ecosystem.Ī lot of the reaction to the previous post echoed that Java 8 is quite old.
We’re not quite there with the APIs yet, sadly, but D8 has us covered with the language features. Having support for the language features and APIs of Java 8 is table stakes at this point. The first post in this series explored Android’s Java 8 support.
For an intro to D8 read “Android’s Java 8 support”. Note: This post is part of a series on D8 and R8, Android’s new dexer and optimizer, respectively.
0 kommentar(er)
