4 ms·

I had read that too and I do not understand at all. What is openjdk beyond a runtime VM ? They do not use what truly qualify as openjdk otherwise they would hav

I had read that too and I do not understand at all. What is openjdk beyond a runtime VM ? They do not use what truly qualify as openjdk otherwise they would have C2 and G1 and therefore true java 8+ support, for free.

kllrnohj 6y ago
They're using the libraries - the part that Oracle is claiming is copyrighted. The java.* packages.
- The_rationalist 6y ago
  javax.* is copyrighted and is now copyleft if you use the jakarta.* namespace instead. as for java.* I don't see how one could have issues, for example Kotlin use and extend the java standard library without any lawsuit. I believe that the issue was that Android devs copy pasted copyrighted code and putted them in their own reimplementation of the jdk without respecting the original authors. Their reimplementation (dalvik & ci) is the root of all evil and is technically a mess with antic java support. It's such a shame that we can't have ZGC or senandoah on android...
  - kllrnohj 6y ago
    > I believe that the issue was that Android devs copy pasted copyrighted code and putted them in their own reimplementation of the jdk without respecting the original authors. Your belief is firmly incorrect. The "copied code" claim was for a 9-line rangeCheck function and was otherwise dropped. The main claim is entirely that the java.* API definitions are copyrighted, and therefore Google's clean room re-implementation of the APIs still violates the copyright of the API itself. Which is a lawsuit that Oracle won, by the way: https://en.wikipedia.org/wiki/Google_v._Oracle_America#First_phase:_API_copyrightability_and_patents https://en.wikipedia.org/wiki/Google_v._Oracle_America#First... The open question at this point is whether a clean-room re-implementation of a copyrighted API for the purposes of compatibility is considered fair use or not. Which so far Oracle has been winning. Which means approximately everything is in copyright violation in the tech world. POSIX, for example, took the API from commercial Unix OS's of the time. The current owners of Unix, Micro Focus, could sue approximately everyone if Oracle wins.
    - The_rationalist 6y ago
      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

They're using the libraries - the part that Oracle is claiming is copyrighted. The java.* packages.

The_rationalist 6y ago
javax.* is copyrighted and is now copyleft if you use the jakarta.* namespace instead. as for java.* I don't see how one could have issues, for example Kotlin use and extend the java standard library without any lawsuit. I believe that the issue was that Android devs copy pasted copyrighted code and putted them in their own reimplementation of the jdk without respecting the original authors. Their reimplementation (dalvik & ci) is the root of all evil and is technically a mess with antic java support. It's such a shame that we can't have ZGC or senandoah on android...
- kllrnohj 6y ago
  > I believe that the issue was that Android devs copy pasted copyrighted code and putted them in their own reimplementation of the jdk without respecting the original authors. Your belief is firmly incorrect. The "copied code" claim was for a 9-line rangeCheck function and was otherwise dropped. The main claim is entirely that the java.* API definitions are copyrighted, and therefore Google's clean room re-implementation of the APIs still violates the copyright of the API itself. Which is a lawsuit that Oracle won, by the way: https://en.wikipedia.org/wiki/Google_v._Oracle_America#First_phase:_API_copyrightability_and_patents https://en.wikipedia.org/wiki/Google_v._Oracle_America#First... The open question at this point is whether a clean-room re-implementation of a copyrighted API for the purposes of compatibility is considered fair use or not. Which so far Oracle has been winning. Which means approximately everything is in copyright violation in the tech world. POSIX, for example, took the API from commercial Unix OS's of the time. The current owners of Unix, Micro Focus, could sue approximately everyone if Oracle wins.
  - The_rationalist 6y ago
    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.