4 ms·

This is an interesting comment. GPL licensed code is divisible, so Google could technically achieve the same thing by adding a comment in the NOTICE file that s

This is an interesting comment. GPL licensed code is divisible, so Google could technically achieve the same thing by adding a comment in the NOTICE file that said Api method signatures are Copyright Oracle, GPL, the rest is Apache. But the NOTICE file doesn't say anything about Oracle at all! Nor did they carry over the openjdk LICENSE file, which adds to the mysteriousness. I only did a cursory examination of the commit. Someone please post if I'm wrong about this.

pron 11y ago
> GPL licensed code is divisible, so Google could technically achieve the same thing by adding a comment in the NOTICE file that said Api method signatures are Copyright Oracle, GPL, the rest is Apache. That doesn't work. GPL is divisible (in fact, you can do whatever you want with the code), but the license must be applied to the entire deliverable, up to (excluding) classpath-linking which is explicitly exempted by the OpenJDK license -- so in this case, the whole runtime minus Google-only packages if they're classpath-linked only. My thought was that Google may simply choose to make Android GPL + classpath exception. The reason for not doing so when Android was young (I can only assume) was the fear that phone vendors would balk at a runtime that doesn't let them make proprietary changes (of course, Linux doesn't either, but I guess the thought was that the phone manufacturers are likely to make changes that are closer to the application). But now, given Android's popularity, phone vendors would swallow whatever license Google imposes on them (and would still be free to make proprietary changes to classpath-linked portions of the runtime). This is a win for everyone: Google gets to expend less effort maintaining the runtime, plus they get Oracle off their back (at least for future Android versions); Oracle gets to have Java (or something close enough to it) on lots of smartphones, and the developer community gets to have true Java interop (with all new Java features), and probably a higher-quality runtime. Later, Google would be free (but not compelled, although that depends on a future settlement) to make Android fully Java compliant with one of the Java standards, but that is an orthogonal issue.
- logicchains 11y ago
  Barely on topic, but since you're the person to ask, would the use of OpenJDK on Android mean that it'd support Pulsar/Quasar?
  - pron 11y ago
    Hmm, this may be orthogonal, but it certainly can't hurt. Quasar already has AOT instrumentation and we're working on making it available on Android as-is. OTOH, even if Android goes OpenJDK, it's doubtful they'll support agents, so you'll have to rely on AOT instrumentation anyway. But to get us back on point, it will certainly make the work of migrating any Java library to Android easier.
- bitmapbrother 11y ago
  This is perhaps the most interesting comment on this topic. The implications for such a licensing change would be enormous for the development community, I believe. The days of OEM's not releasing their source code, for changes to the Android ASL parts, may finally be over. I'm curious, though, as to why you believe Google would expend less effort developing the runtime considering the different trajectories of ART and the JVM.
  - pron 11y ago
    > I'm curious, though, as to why you believe Google would expend less effort developing the runtime considering the different trajectories of ART and the JVM. Because the runtime is much more than just the VM. If you look at the breakdown of the JDK source tree[1], you'll see that it's 77% Java and only 18% C/C++ (although the Android ecosystem is already making indirect use of some of that Java code, when it uses tools like javac, javadoc etc.). Also, Google might choose to use HotSpot or parts of it instead of or in addition to ART. Of course, all of this is pure speculation (and wishful thinking) on my part. [1]: https://github.com/dmlloyd/openjdk https://github.com/dmlloyd/openjdk
- xorcist 11y ago
  > the fear that phone vendors would balk at a runtime that doesn't let them make proprietary changes In retrospect, the ability for phone vendors to make proprietary changes to the system has been a huge problem for Google, Android as a platform, and the community in general.

pron 11y ago

> GPL licensed code is divisible, so Google could technically achieve the same thing by adding a comment in the NOTICE file that said Api method signatures are Copyright Oracle, GPL, the rest is Apache. That doesn't work. GPL is divisible (in fact, you can do whatever you want with the code), but the license must be applied to the entire deliverable, up to (excluding) classpath-linking which is explicitly exempted by the OpenJDK license -- so in this case, the whole runtime minus Google-only packages if they're classpath-linked only. My thought was that Google may simply choose to make Android GPL + classpath exception. The reason for not doing so when Android was young (I can only assume) was the fear that phone vendors would balk at a runtime that doesn't let them make proprietary changes (of course, Linux doesn't either, but I guess the thought was that the phone manufacturers are likely to make changes that are closer to the application). But now, given Android's popularity, phone vendors would swallow whatever license Google imposes on them (and would still be free to make proprietary changes to classpath-linked portions of the runtime). This is a win for everyone: Google gets to expend less effort maintaining the runtime, plus they get Oracle off their back (at least for future Android versions); Oracle gets to have Java (or something close enough to it) on lots of smartphones, and the developer community gets to have true Java interop (with all new Java features), and probably a higher-quality runtime. Later, Google would be free (but not compelled, although that depends on a future settlement) to make Android fully Java compliant with one of the Java standards, but that is an orthogonal issue.

logicchains 11y ago
Barely on topic, but since you're the person to ask, would the use of OpenJDK on Android mean that it'd support Pulsar/Quasar?
- pron 11y ago
  Hmm, this may be orthogonal, but it certainly can't hurt. Quasar already has AOT instrumentation and we're working on making it available on Android as-is. OTOH, even if Android goes OpenJDK, it's doubtful they'll support agents, so you'll have to rely on AOT instrumentation anyway. But to get us back on point, it will certainly make the work of migrating any Java library to Android easier.
bitmapbrother 11y ago
This is perhaps the most interesting comment on this topic. The implications for such a licensing change would be enormous for the development community, I believe. The days of OEM's not releasing their source code, for changes to the Android ASL parts, may finally be over. I'm curious, though, as to why you believe Google would expend less effort developing the runtime considering the different trajectories of ART and the JVM.
- pron 11y ago
  > I'm curious, though, as to why you believe Google would expend less effort developing the runtime considering the different trajectories of ART and the JVM. Because the runtime is much more than just the VM. If you look at the breakdown of the JDK source tree[1], you'll see that it's 77% Java and only 18% C/C++ (although the Android ecosystem is already making indirect use of some of that Java code, when it uses tools like javac, javadoc etc.). Also, Google might choose to use HotSpot or parts of it instead of or in addition to ART. Of course, all of this is pure speculation (and wishful thinking) on my part. [1]: https://github.com/dmlloyd/openjdk https://github.com/dmlloyd/openjdk
xorcist 11y ago
> the fear that phone vendors would balk at a runtime that doesn't let them make proprietary changes In retrospect, the ability for phone vendors to make proprietary changes to the system has been a huge problem for Google, Android as a platform, and the community in general.