3 ms·

Didn't Sun open-source Java before Android launched (but after Android had already done a significant amount of implementation internally)? Looks like they open

by geofft 6y ago

Didn't Sun open-source Java before Android launched (but after Android had already done a significant amount of implementation internally)? Looks like they open-sourced it in fall 2006. Android was founded in fall 2003 and acquired by Google in summer 2005, but I can't find any public references to it being Java-based from before 2007. Android is now using OpenJDK and (I assume) not paying anything to Oracle for it. I think they could theoretically have rebased on top of OpenJDK in early 2007 if they expected it to be a serious legal problem, and Sun would have been no better off.

pjmlp 6y ago
It was dual licensed, and JavaSE license did not apply to embedded devices deployment. Android is not using OpenJDK as such, that is Google's marketing. What Google is doing is cherry picking code from OpenJDK and adapting it to Android. What they care about is keeping Kotlin's FFI to Java libraries relevant. In Android 11 there are a couple of Java APIs all the way to 13, that they again cherry picked from. https://android-developers.googleblog.com/2020/07/11-weeks-of-android-languages.html https://android-developers.googleblog.com/2020/07/11-weeks-o... It is quite easy to track from their Gerrit which stuff gets copied from OpenJDK and what keeps being ignored. They always end their Java update announcements asking for what APIs are relevant, while for anyone else it is clear that only 100% matters. And we aren't even getting into language features or JVM bytecodes that don't have parity with ART ones. Android Java is Google's J++. Also for selling Kotlin they always use Java 7/8 code style when comparing against Kotlin code.
- ptx 6y ago
  Java has editions and profiles that implement different APIs and features, so Android's subsetting doesn't seem all that different. MIDP had even more missing.
  - pjmlp 6y ago
    Except those editions have reference documentation that specifies what they provide, across all COMPLIANT implementations. Android Java is more like cowboy coding, whatever needed to keep Kotlin relevant libraries going on Android. And to know what Java API is available one needs to crawl Android documentation to track down on which API level they got added into the platform. The irony is that I am yet to see Android Studio, Gradle and Kotlin running to top of ART/desktop, a JVM free toolchain. Which apparently would be the direction that Google is driving into.
- jillesvangurp 6y ago
  Actually, J2ME was open sourced as well but with one crucial difference: it was GPL v2 but without the classpath exception they used for the regular version. With the classpath exception, dynamically linking class files is allowed. Normally this would be a form of creating a derived work thus triggering the virality of the license. This is crucial because it meant phone manufacturers could not take the OSS version and be able to ship it without having to OSS all their proprietary stuff linked against it. Sun was making a bit of money licensing J2ME to just about all phone manufacturers. The Gnu classpath was unusable for mobile phone manufacturers for the same reason: it would expose them to its viral clauses. The Google & Oracle conflict is related to this because when Google bought Android (in 2004?), they ended up using Apache Harmony, which was a newly created project backed by IBM with an Apache licensed implementation of the Java standard library. It allowed Google to opt out of Sun's restrictive licensing deals, dodge licensing issues with gnu licensed code, and at the same time ignore the design by committee style API design that Sun insisted on with the rest of the industry. Basically, it enabled them to run the whole of Java as they had their own vm and standard library implementation. Given improvements in mobile hardware, this was an obvious thing to want to do technically by that time. After Android shipped, there was little to no point at all to J2ME and it quickly became a thing of the past. So, when Oracle bought Sun in 2010, all of that had already happened half a decade earlier. IBM pulled the plug on Harmony shortly after the acquisition and Google eventually incorporated much of Openjdk into Android to replace their Apache Harmony based implementation and also to modernize the code base. This is still licensed with the classpath exception; so they can do this.
  - pjmlp 6y ago
    Except the little fact that Android Java has become Google's J++, forking the Java community, while creating lots of pain for any Java library author that would like to support Android as deployment target. Google had the opportunity to fix up their screw up by buying Sun, which they didn't, most likely hoping that Sun would sink silently, and they would get away with their little power games and industrial torpedoes. Unfortunately for them, and fortunately for us Java devs, as I wouldn't like the Android architects to design Java, Oracle did not thought the same way.

by geofft 6y ago

pjmlp 6y ago

It was dual licensed, and JavaSE license did not apply to embedded devices deployment. Android is not using OpenJDK as such, that is Google's marketing. What Google is doing is cherry picking code from OpenJDK and adapting it to Android. What they care about is keeping Kotlin's FFI to Java libraries relevant. In Android 11 there are a couple of Java APIs all the way to 13, that they again cherry picked from. https://android-developers.googleblog.com/2020/07/11-weeks-of-android-languages.html https://android-developers.googleblog.com/2020/07/11-weeks-o... It is quite easy to track from their Gerrit which stuff gets copied from OpenJDK and what keeps being ignored. They always end their Java update announcements asking for what APIs are relevant, while for anyone else it is clear that only 100% matters. And we aren't even getting into language features or JVM bytecodes that don't have parity with ART ones. Android Java is Google's J++. Also for selling Kotlin they always use Java 7/8 code style when comparing against Kotlin code.

ptx 6y ago
Java has editions and profiles that implement different APIs and features, so Android's subsetting doesn't seem all that different. MIDP had even more missing.
- pjmlp 6y ago
  Except those editions have reference documentation that specifies what they provide, across all COMPLIANT implementations. Android Java is more like cowboy coding, whatever needed to keep Kotlin relevant libraries going on Android. And to know what Java API is available one needs to crawl Android documentation to track down on which API level they got added into the platform. The irony is that I am yet to see Android Studio, Gradle and Kotlin running to top of ART/desktop, a JVM free toolchain. Which apparently would be the direction that Google is driving into.
jillesvangurp 6y ago
Actually, J2ME was open sourced as well but with one crucial difference: it was GPL v2 but without the classpath exception they used for the regular version. With the classpath exception, dynamically linking class files is allowed. Normally this would be a form of creating a derived work thus triggering the virality of the license. This is crucial because it meant phone manufacturers could not take the OSS version and be able to ship it without having to OSS all their proprietary stuff linked against it. Sun was making a bit of money licensing J2ME to just about all phone manufacturers. The Gnu classpath was unusable for mobile phone manufacturers for the same reason: it would expose them to its viral clauses. The Google & Oracle conflict is related to this because when Google bought Android (in 2004?), they ended up using Apache Harmony, which was a newly created project backed by IBM with an Apache licensed implementation of the Java standard library. It allowed Google to opt out of Sun's restrictive licensing deals, dodge licensing issues with gnu licensed code, and at the same time ignore the design by committee style API design that Sun insisted on with the rest of the industry. Basically, it enabled them to run the whole of Java as they had their own vm and standard library implementation. Given improvements in mobile hardware, this was an obvious thing to want to do technically by that time. After Android shipped, there was little to no point at all to J2ME and it quickly became a thing of the past. So, when Oracle bought Sun in 2010, all of that had already happened half a decade earlier. IBM pulled the plug on Harmony shortly after the acquisition and Google eventually incorporated much of Openjdk into Android to replace their Apache Harmony based implementation and also to modernize the code base. This is still licensed with the classpath exception; so they can do this.
- pjmlp 6y ago
  Except the little fact that Android Java has become Google's J++, forking the Java community, while creating lots of pain for any Java library author that would like to support Android as deployment target. Google had the opportunity to fix up their screw up by buying Sun, which they didn't, most likely hoping that Sun would sink silently, and they would get away with their little power games and industrial torpedoes. Unfortunately for them, and fortunately for us Java devs, as I wouldn't like the Android architects to design Java, Oracle did not thought the same way.