4 ms·

I stand corrected yet while the legal implications are interesting and important the point still is that Android should totally switch to openjdk, end of story.

kllrnohj 6y ago
> important the point still is that Android should totally switch to openjdk, end of story Not "end of story" at all - why should Android switch? You mentioned ZGC & Shenandoah, but why do you think that would be a benefit? Have you actually tried benchmarking your app in ART vs. OpenJDK? Do you have any clue at all if ZGC would even be an improvement in your workloads, or the workloads of a typical Android app for that matter? There's a lot of really cool work going on in that space, but for example ZGC's NUMA awareness won't do diddly shit for your Android app, so things like that are pretty moot. Meanwhile ART has optimizations that OpenJDK doesn't, like importing profiles to AOT compile parts of an app that's never been run locally before: https://android-developers.googleblog.com/2019/04/improving-app-performance-with-art.html https://android-developers.googleblog.com/2019/04/improving-... Similarly OpenJDK's startup time & memory usage is historically quite bad, because it's just not a primary use case for them in the same way it is for ART. OpenJDK finally got some improvements in those areas very very recently ( https://cl4es.github.io/2019/11/20/OpenJDK-Startup-Update.html https://cl4es.github.io/2019/11/20/OpenJDK-Startup-Update.ht... ), but it's still not good and far from being obviously superior on all metrics to ART. And ART isn't standing still, either, with new improvements like even faster incredibly fast FFI support: https://android-review.googlesource.com/c/platform/art/+/1321919 https://android-review.googlesource.com/c/platform/art/+/132... Which is important for achieving things like 120hz 2D UI rendering while also running on incredibly slow in-order non-speculating power saving little cores. Which is a use case & scenario OpenJDK has never been asked to deal with nor optimized to handle. OpenJDK isn't the end-all be-all excellent-at-everything pinnacle here. After all, nobody ever accused a Java desktop application of being fast & responsive.
- pjmlp 6y ago
  > OpenJDK isn't the end-all be-all excellent-at-everything pinnacle here. Indeed, that is why since around 2000 there are multiple JVM implementations, including plenty of them with AOT and JIT cache capabilities. The now gone WebSphere Realtime JVM already supported importing profiles for their AOT/JIT compilers. And in what concerns phone devices, Microsoft did it first with their Cloud compiler for MSIL on Windows Store, first with MDIL/Bartok taken from Singularity for Windows Phone 8.x, followed up by the .NET Native toolchain on Windows 10. Google's marketing is good, but not very influential for those that actually know the Java eco-system and the offerings available across all major vendors. Also here is the confirmation that they will carry on cherry picking OpenJDK features instead of full compatibility. " u/dessert_maker: We pick additional OpenJDK APIs for each Android release based on inputs from our developers. Android 11 will support additional APIs from OpenJDK 9. Everyone that is developing in Java and Kotlin should be able to take advantage of these newer additions. In addition, we have added library desugaring to the build toolchain in Android Studio to make a wide variety of APIs across OpenJDK 8, 9, 10, and 11 available regardless of what version of Android your app runs on. We expect to add support to the platform for more modern APIs (11,13,14) based on the level of adoption we see from our broader developer community in future versions. As mentioned in last year's AMA, making the overall runtime updatable is something we are thinking about as part of Project Mainline." -- https://old.reddit.com/r/androiddev/comments/hk3hrq/were_on_the_android_engineering_team_ask_us/fxgmdz1/ https://old.reddit.com/r/androiddev/comments/hk3hrq/were_on_... So thank you Google for Android Java and like J++, forcing Java library authors to code specifically for Android, or just ignore it and focus on the myriad of JVM compatible implementations instead.

kllrnohj 6y ago

> important the point still is that Android should totally switch to openjdk, end of story Not "end of story" at all - why should Android switch? You mentioned ZGC & Shenandoah, but why do you think that would be a benefit? Have you actually tried benchmarking your app in ART vs. OpenJDK? Do you have any clue at all if ZGC would even be an improvement in your workloads, or the workloads of a typical Android app for that matter? There's a lot of really cool work going on in that space, but for example ZGC's NUMA awareness won't do diddly shit for your Android app, so things like that are pretty moot. Meanwhile ART has optimizations that OpenJDK doesn't, like importing profiles to AOT compile parts of an app that's never been run locally before: https://android-developers.googleblog.com/2019/04/improving-app-performance-with-art.html https://android-developers.googleblog.com/2019/04/improving-... Similarly OpenJDK's startup time & memory usage is historically quite bad, because it's just not a primary use case for them in the same way it is for ART. OpenJDK finally got some improvements in those areas very very recently ( https://cl4es.github.io/2019/11/20/OpenJDK-Startup-Update.html https://cl4es.github.io/2019/11/20/OpenJDK-Startup-Update.ht... ), but it's still not good and far from being obviously superior on all metrics to ART. And ART isn't standing still, either, with new improvements like even faster incredibly fast FFI support: https://android-review.googlesource.com/c/platform/art/+/1321919 https://android-review.googlesource.com/c/platform/art/+/132... Which is important for achieving things like 120hz 2D UI rendering while also running on incredibly slow in-order non-speculating power saving little cores. Which is a use case & scenario OpenJDK has never been asked to deal with nor optimized to handle. OpenJDK isn't the end-all be-all excellent-at-everything pinnacle here. After all, nobody ever accused a Java desktop application of being fast & responsive.

pjmlp 6y ago
> OpenJDK isn't the end-all be-all excellent-at-everything pinnacle here. Indeed, that is why since around 2000 there are multiple JVM implementations, including plenty of them with AOT and JIT cache capabilities. The now gone WebSphere Realtime JVM already supported importing profiles for their AOT/JIT compilers. And in what concerns phone devices, Microsoft did it first with their Cloud compiler for MSIL on Windows Store, first with MDIL/Bartok taken from Singularity for Windows Phone 8.x, followed up by the .NET Native toolchain on Windows 10. Google's marketing is good, but not very influential for those that actually know the Java eco-system and the offerings available across all major vendors. Also here is the confirmation that they will carry on cherry picking OpenJDK features instead of full compatibility. " u/dessert_maker: We pick additional OpenJDK APIs for each Android release based on inputs from our developers. Android 11 will support additional APIs from OpenJDK 9. Everyone that is developing in Java and Kotlin should be able to take advantage of these newer additions. In addition, we have added library desugaring to the build toolchain in Android Studio to make a wide variety of APIs across OpenJDK 8, 9, 10, and 11 available regardless of what version of Android your app runs on. We expect to add support to the platform for more modern APIs (11,13,14) based on the level of adoption we see from our broader developer community in future versions. As mentioned in last year's AMA, making the overall runtime updatable is something we are thinking about as part of Project Mainline." -- https://old.reddit.com/r/androiddev/comments/hk3hrq/were_on_the_android_engineering_team_ask_us/fxgmdz1/ https://old.reddit.com/r/androiddev/comments/hk3hrq/were_on_... So thank you Google for Android Java and like J++, forcing Java library authors to code specifically for Android, or just ignore it and focus on the myriad of JVM compatible implementations instead.