4 ms·

If Android switch to openjdk like everybody else, they'll be lawsuit proof

kllrnohj 6y ago
They did: https://arstechnica.com/tech-policy/2016/01/android-n-switches-to-openjdk-google-tells-oracle-it-is-protected-by-the-gpl/ https://arstechnica.com/tech-policy/2016/01/android-n-switch... The runtime remains ART, though, but that wasn't the issue in the lawsuit.
- The_rationalist 6y ago
  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
  They did not, that article doesn't show the actual reality. As one can follow up on AOSP Gerrit comments, code from OpenJDK gets cherry picked into Android. https://android-review.googlesource.com/q/project:platform%252Flibcore https://android-review.googlesource.com/q/project:platform%2...

They did: https://arstechnica.com/tech-policy/2016/01/android-n-switches-to-openjdk-google-tells-oracle-it-is-protected-by-the-gpl/ https://arstechnica.com/tech-policy/2016/01/android-n-switch... The runtime remains ART, though, but that wasn't the issue in the lawsuit.

The_rationalist 6y ago
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
They did not, that article doesn't show the actual reality. As one can follow up on AOSP Gerrit comments, code from OpenJDK gets cherry picked into Android. https://android-review.googlesource.com/q/project:platform%252Flibcore https://android-review.googlesource.com/q/project:platform%2...