Why Microsoft Loves Google Android, Take 2

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!

Comments

[Laurent Szyster]

Richard,

Windows does not love Android more than Sun and its mob of proprietary vendor. If only for one reason: it provides a credible alternative to WindowsCE, something that JavaME obviously failed to incarnate.

Android enables Java developers to target a mobile Linux plate-form with a full stack of API that leverage the best breed of open source C libraries to deliver optimal performances.

It should give Microsoft some nightmares, because mobile computers are the future of personal computing.

Now, the fact that Android's API has been developed outside the JCP is a good thing.

Because up until now the mob of proprietary Java vendor have abused the standardization process to come up with what we programmers refer to as "Worse Than Failure" (J2EE and JavaME is a perfect example of the kind shit usually produced by "industry standard" bodies).

Dalvik's VM is the best thing that could have ever happened to Java the language: a virtual machine that does not gobble RAM, starts up fast, binds efficiently to C libraries, collect garbage in a sane way, etc. Here too Google's engineers were smart enough to break away from the vendor mob and provide the community with a way out of the dead end that the JVM specs have become.

[Richard Monson-Haefel]

Hi Laurent,

You make some excellent points. I also like Android - its a nice platform, but that doesn't change the fact that its non-compliant with the JCP's specifications for Java ME and Java SE. It's probably a good thing for the industry, but not a good thing for the JCP. Hopefully, this will help the JCP correct its own errors regarding Java ME.

Also lets not forget the Mobile System Architecture (MSA), which has potential in its own right. Its a tighter specification than previous Java ME stacks (i.e. GEN-1 and JTWI)and offers a lot of functionality. MSA is just starting to gain traction, but right now only a handful of device models support it. This will change if Nokia adopts it as promised in the S60 3rd Edition, Feature 2 release.

Anyway, lots of things to think about.

[Dalibor Topic]

Today, Java industry's most important competitive weapon against Microsoft is the Free software reference implementation.

[jwr]

Hi Dick.

The main problem I have with your articles is you seem to want to define Java as living and dieing based solely on its use in cell phones. The reality is that there are many, many more implementations and uses of Java in more conventional PC style environments. Those environments will continue to foster growth in the Java space.

Give cell phones another 2 or 3 years, with fuel cell technology providing power, and you will see Java continuing to phase out ME, Android continuing to converge on SE, and .Net continuing to be proprietary.

The winner will be whatever the developers are willing to download, install and use. Right now, developers seems to want to use environments where the language constructs remains consistent, the IDEs work across multiple O/Ss, startup cost is low (or even free), and they can use other tools, libraries, etc. that they are already familiar with.

Based on that, I'm not sure there will ever be only one solution in use, but I'm betting any that are in use will be pretty damn good.