Over a million developers have joined DZone.

Debating Brendan Eich Over Android-OpenJDK Move

Shai Almog and Brendan Eich debate the Android-OpenJDK move: see what this migration means, and doesn't mean.

· Mobile Zone

Visually compose APIs with easy-to-use tooling. Learn how IBM API Connect provides near-universal access to data and services both on-premises and in the cloud, brought to you in partnership with IBM.

I had a big post ready for today, but after a long Twitter debate with @BrendanEich, I had to write a followup as Twitter is a poor medium for that level of debate.

This started with a blog post from Andreas Gal who effectively took the exact opposite stance to mine on Google's move to OpenJDK.

Then Mr. Eich picked it up:

To be fair, I'm biased. I work on a cross-platform mobile toolchain, and I'm an ex-Sun guy. But I think that the fact that the senior Java/Android community has embraced this change as a positive one says a lot. Also, Android compatibility is crucial in our line of business where we need code to work for all versions of Android without a problem...

Let's go over the claims made both on Twitter and in the article.

Oracle Sinks its Claws into Android

Using a title like this is misleading, clickbait, and antagonistic.

I don't think Oracle made any friends with the lawsuit, overall the vibe in the Java community is that this was a mistake that didn't help anyone. The thing is that OpenJDK is GPL and so Oracle doesn't really "own" it and doesn't really gain much except in maybe some "respect."

OpenJDK is GPL+CPE so Google can use it without paying Oracle a dime (just like Linux distros do). It also features a patent grant which means that if Google passes the TCK's (meaning they are Java compatible which is a good thing(TM)). they will receive a license for the patents and Oracle can't legally sue them over patents used in the VM!

So effectively the title is pretty wrong, Google gets newer up to date Java code for free, and the Java OSS community can focus on one code base (for security analysis, performance etc.), instead of two. Compatibility will rise although it's already there or 99.99% there.

This Was Forced Thru Legal Process

Totally true. That doesn't make it bad for us although one could wish that peace was reached without the legal system.

Google took a calculated risk when Android was young which made a lot of sense when Sun owned Java. The reason for taking a specific action doesn't mean it's bad, I would wager that one of the reasons Google avoided adopting OpenJDK in the past was legal as well.

Apache License vs. GPL License

As I was writing this a great article was posted that pretty much answers this better than I could. I chose to leave my thoughts below since it's simpler to read.

It's harder to get people to adopt GPL, but they did it with Linux despite there being BSD-licensed alternatives that are pretty good. Google already used Linux as the core so already has some GPL code.

The original post already corrected the fact that OpenJDK didn't exist when Android came out. But that wasn't the sticking point with Sun. Google wanted the Apache license and Sun was making a lot of money over mobile so this was a big problem/conflict.

The reason Google insisted on Apache was due to operators who were the gatekeepers Google needed to get past to control mobile. Now that it's already in and controls the market adding more GPL code is meaningless just as operators have gone down in their power since the days Android launched. Overall this changed nothing, in Android M you had X lines of GPL code from Linux and now you will have more lines of GPL+CPE code no real difference.

All This Code and Technology Churn Will Have massive Implications for Android

@Codename_One@deanrl@enleeten@hhariri To recap, @andreasgal & I say MLOCs of forced change carry hi incompat risk, all agree that'd suck.

— BrendanEich (@BrendanEich) January 6, 2016

This is far from accurate. To be fair, only Google engineers know the approximate extent of work and only after the fact will we fully know the implications. However, I've ported JVM's for years both at Sun and at Codename One. I'm very familiar with the issues of getting code to work on the desktop VM and the mobile VM and specifically with Android issues.

From my experience, Android VM compatibility issues are 80% vendor/operator issues (weird stuff with device specific behaviors), and 20% issues in the android.* packages. We ran into no issue whatsoever with the harmony code being different from Java 7 or 8 in terms of compatibility. It's possible that such edge cases exist but I doubt it would be a big deal and it would allow better server/mobile shared code.

@deanrl@Codename_One@mosheeshel@enleeten@hhariri@andreasgal Developer reward is later and second or third order. Risk+cost first order.

— BrendanEich (@BrendanEich) January 5, 2016

The existing Harmony classes are old and stale, no one touched them in years so a big change of removing and replacing them with other classes will take some effort from Google's developers. That's a fact. It's years worth of changes that now Google needs to do in a single swoop but it's something Google should have done in the past to bring newer classes/features into place. The alternatives are doing nothing or doing this slowly at their own pace both of which would be bad.

Java has amazing TCK's that check compatibility, the likelihood of something breaking is relatively low. We have been porting Java code to Android for years with absolutely no issues related to these API's so on the surface this looks like something that would go unnoticed for most existing apps. If something will stop working or behave radically different Google has the ability to work in compatibility mode for that specific API built into their manifest target SDK system.

While this is a big change in terms of lines of code most of those lines are already written and well tested so it looks like a big change but is much smaller in scope than the LOC would make it seem.

Prior changes made by Google even for Marshmallow are huge earth shattering changes to the basic permissions system of Android that has been in place since 1.x days. That is probably a far bigger problem for everyday Android developers than this change.

Device compatibility with no-brand devices on the far east market and non-google devices are also far bigger problems for an Android developer than this will ever be.

@deanrl@Codename_One@mosheeshel@enleeten@hhariri@andreasgal 2/ Bill Joy of Sun persuaded us to kill Kipp's VM as bug4bug is impossible.

— BrendanEich (@BrendanEich) January 6, 2016

I worked at Sun for years and never got face time with Bill Joy...ugh.

What was true in 1995 is no longer true today, Java now has a robust TCK and language specification. It has quite a few separate compliant VM's and is pretty well understood. I think Google did an amazing job at compliance and it's clear they followed the JVM specification well.

This Change Won't Benefit Users

@deanrl@Codename_One@mosheeshel@enleeten@hhariri@andreasgal Developer reward is later and second or third order. Risk+cost first order.

— BrendanEich (@BrendanEich) January 5, 2016

While there are some changes that benefit users directly, most software development changes don't. Not all developers benefit from every language/API feature either.

Users will benefit from the fact that code bases are unified and security auditing will now focus on a more uniform code base. A lot of the standard Java tools might work better with Android, as a result, e.g. the current level of Android profiling support is HORRIBLE when compared to desktop Java or even iOS.

iOS has excellent profiling support thanks to d-trace (technology from Sun) so hopefully we'll see an eventual peace process and more collaboration to benefit everyone.

Final Word

@Codename_One@mosheeshel@enleeten@hhariri@andreasgal Any nontrivial work raises costs+risks. As technologist & founder I see it plainly.

— BrendanEich (@BrendanEich) January 5, 2016

I think this sums up a lot of the claims. Yes, this will take Google some effort. Yes, a few apps might be affected, I'd wager this would be far less than those affected by the Marshmallow changes and Google has the tools to alleviate a lot of that problems (SDK version hints).

Would Google have done it without the lawsuit? Maybe...if there was no lawsuit and Java 8 was out, maybe Google would have adopted OpenJDK or maybe they would have dedicated the engineering effort to add this support into Android's Harmony. Either way, a lot of engineering effort would have gone out whether the lawsuit was there or not.

Google's current version of Java is old and stale, replacing it is a good thing for everyone even though it's not free of any costs. But everything has a cost and this one is probably worth paying in the long run.

The Mobile Zone is brought to you in partnership with Strongloop and IBM.  Visually compose APIs with easy-to-use tooling. Learn how IBM API Connect provides near-universal access to data and services both on-premises and in the cloud.


Published at DZone with permission of Shai Almog, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}