Blogger: Richard Monson-Haefel
Ed Burnette wrote a rebuttal to my blog post, "Why Microsoft Loves Google Android", which was high-spirited. Reputation bashing aside, I like high-spirited debates. My favorite quote these-days is, "Argue as if you were right, listen as if you were wrong" by Karl Weick. It's a good ground rule for any debate. It allows you to be passionate while also giving serious consideration to your opponent's arguments.
I want to apologize for my imprecise language in my original post. Ed’s misunderstanding of my thesis makes it clear to me that I didn’t explain myself very well, and I must admit that I used terminology inconsistently. I’d like to take another try at it, and this time I’ll make sure that I clearly explain the subtleties of forks, platform compatibility, and platform fragmentation. I also want to make it clear that I’m not trying to bash Android. I like Android. I’m just saying that Android is a threat to Java standards.
Is Android a fork?
First let me differentiate the Java Programming Language from the Java Platform. The Java Programming Language is a programming language syntax. The Java Platform includes the Java Language, but it’s much more than that. The Java Platform is a three-legged stool consisting of the core Java APIs (packages, frameworks, and libraries), the Java bytecode (the compiled, executable format), and the Java Virtual Machine (the runtime system that executes bytecode). Note that the language syntax is actually the least important aspect of the Java Platform. Other language syntaxes (e.g., Groovy, JRuby, JPython) can be used to write Java bytecode applications that execute in the JVM.
In order to qualify as a Java-compatible platform, a platform must implement all three of these legs as required by the Java SE or Java ME specifications. (I'm leaving Java EE out of this because it’s not germane to this discussion.) If a software distribution does not depend on or implement all three legs of the stool (APIs, bytecode, and virtual machine) then it’s not a Java Platform – it’s a fork.
Android uses the Java programming language and some of the Java ME and SE APIs, but it uses a different executable format (i.e., not bytecode) and a different virtual machine (i.e., not a JVM). You cannot take Java bytecode generated using a Java ME or Java SE environment and execute it on Android. Therefore it is a fork. That is not a value statement; it’s a fact. Perhaps "fork" is an overloaded term these days. If there is a better word for implementing some, but not all, of the required parts of a software platform – any platform - then please tell me.
Compatibility vs. Fragmentation
Java compatibility is very different from Java fragmentation, but the differences are subtle enough to confuse anybody. The primary value proposition of Java is “write once, run anywhere.” Sun Microsystems and the JCP attempt to fulfill this value proposition through compatibility testing. When a vendor (commercial or open source) implements a Java standard, they have to submit their implementation to compatibility testing if they want to use the brand and say that the product is compatible. This is the role of the TCK, which is a required part of any JCP Java standard. Android, which uses only a subset of the Java ME and SE APIs, and is compiled into something other than Java bytecode and does not run on a JVM, is incompatible with both Java ME and Java SE.
Fragmentation is different. Fragmentation refers to what specific set of APIs a developer can realistically expect to find in any compatible implementation of a platform. Java ME, for example, is fragmented and the reason for that is the plethora of optional APIs defined by the JCP. A Java ME-compatible platform is required to implement the core Java ME APIs, but optional APIs are – well, optional. Vendors (device manufacturers and mobile network operators) are free to implement whatever optional APIs they wish and still be Java ME compliant. (They are also free to implement proprietary APIs unique to a specific device or provider.) The result is that applications that depend on optional APIs only work on devices that support those APIs. Sadly, so much of Java ME is optional that it makes it difficult to write an application that can run on any mobile device. But that is a different problem from compatibility. For example, RIM provides a compatible Java ME implementation for BlackBerry. The BlackBerry implementation passes the compatibility tests – no problem. But, Blackberry supports a subset of the optional APIs, plus it provides a bunch of proprietary APIs. A Java ME application that uses an optional API not supported by BlackBerry devices won’t run on a BlackBerry. Also an application written that uses a proprietary BlackBerry API won’t run on any other device.
It turns out that the API fragmentation exemplified by the Java ME platform is just as bad for the Java platform as incompatibility. Microsoft is not only happy about Android’s incompatibility with Java ME and Java SE, it’s been extremely thrilled about the API fragmentation already found in Java ME. There is another major difference between compatibility and fragmentation: Fragmentation can be fixed within the Java Community Process (JCP) by defining umbrella specifications. For example, the new Mobile System Architecture (MSA) is a Java ME umbrella specification that requires implementation of specific optional APIs in order to be compatible. That helps but it’s not silver bullet. Intentional incompatibility, on the other hand, cannot be addressed by the JCP. If a vendor, such as Google, wants to create a product that is non-compatible it can do so— it just can’t use the platform name (i.e. Java ME or Java SE) to describe the product. Google doesn’t use the brands Java ME or Java SE; it calls its platform Android. It’s a non-compatible implementation of Java.
Is Android detrimental to Java ME and SE, and does that make Android evil?
I'm not saying that Java is some kind of holy ground and that competition with the Java platform is bad. Android is not bad like world hunger is bad. It's just not good for the Java ME and Java SE standards. The reason is simple: Android establishes a precedent that's at odds with the Java platform’s fundamental value proposition: Write once, run everywhere. Android, because it’s neither Java ME nor Java SE, establishes a precedent for implementing platforms that use the Java programming language any way you please rather than according to the standards set by the Java Community Process. This has implications that go far beyond Java ME.
My main thesis is this: If Android succeeds as it is currently defined then the entire Java platform, including Java SE, is in trouble. Android's success sends a clear message: Standardization of Java is not important; Write once, run anywhere is not important. That's the antithesis of what the Java platform is all about. Android is not bad like world hunger is bad, it’s just not good for existing Java standards.
While Android may not be good for the Java ME and Java SE standards its impact over all could be very positive for the Java industry. Android will force Sun and the JCP to reconsider the Java ME and Java SE standards. It may even force the development of a new platform that is slimmer than Java SE but not fractured like Java ME. That could be a big win for the Java industry in general. However, until that time, Android adds more meat to the confusing pot that is Java on mobile devices. This can only benefit competing mobile platforms such as Microsoft Windows Mobile.
Android also sets a precedent that is seriously detrimental to the Java Community Process. It asserts that creating non-compatible implementations, forks if you will, is a viable business model. If other vendors pursue this same strategy, the JCP’s ability to enforce compatibility and standards will diminish. Over time the JCP could be rendered completely irrelevant. This too is a benefit to Microsoft and other vendors and platforms that compete with Java. Today, one of the Java industry’s most important competitive weapon against Microsoft .NET is the use of a standardization process (i.e. JCP) which enforces compatibility. Without that, the Java industry is unified around nothing and becomes a mob of proprietary implementations rather than industry founded on a set of standards. Microsoft can compete much more effectively against a mob of proprietary products than it can against a unified group of vendors.
Update: Ed Burnett has posted another rebuttal to this post. You can read it here - he makes a lot of good points and its worth reading. Thanks, Ed!