Well... I was right.
Well... I was right.
Wasn’t Sun’s main issue that they were selling extremely expensive hardware and a proprietary OS that were completely overtaken by x86 and Linux?
I remember getting to play with the very expensive hardware they’d handout to startups in the late 90’s and early 00’s. It was good hardware, but it wasn’t so much better than the slightly more buggy and much less costly Linux systems at the time.
Geniuses with tech, but maybe not so good on the business side?
Also a good read: https://www.atlasobscura.com/articles/hanoi-rat-massacre-190...
It turned out the hunters would rather amputate a live animal’s tail than take a healthy rat, capable of breeding and creating so many more rats—with those valuable tails—out of commission. There were also reports that some Vietnamese were smuggling foreign rats into the city. And then the final straw: Health inspectors discovered, in the countryside on the outskirts of Hanoi, pop-up farming operations dedicated to breeding rats.”
More importantly, I wouldn't trust a word that Larry Ellison says - particularly when the primary purpose of the article was to boost the Oracle share price by explaining that Sun would be additive to that quarters profits. I'm not saying that Scott McNeally or Jonathan Schwartz were great execs - I have no idea - but I think you have to look at the goal of the article.
If they had learned these skills from companies like RH/SUSE/IBM, then Java would have been in much better hands today.
Secondly, with Sun you would never had gotten AOT, because they saw it as something that 3rd party vendors like Oracle and IBM should care about, they were fully into "JIT or bust", and MaximeVM would have followed the same path as SPOTs, instead of turning into GraalVM.
So if you have any problem with Oracle, thank Google in first place.
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.
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.