So if you have any problem with Oracle, thank Google in first place.
So if you have any problem with Oracle, thank Google in first place.
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.
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-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.
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.
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.
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.
So I had to deal with Solaris, Aix, HP-UX, and Windows NT/2000.
We also rented servers for in-house development.
Their rates were just like everyone else on the Fortune 500 world.