X
Tech

Richard Monson-Haefel responds, still gets it wrong

Last week I took Burton group analyst Richard Monson-Haefel to task for a post he made about Android. Yesterday he responded and attempted to clarify his position in "Why Microsoft Loves Google Android, Take 2". While Richard deserves credit for being a good sport about my criticism, I still disagree with him. Here's why.
Written by Ed Burnette, Contributor

Last week I took Burton group analyst Richard Monson-Haefel to task for a post he made about Android. Yesterday he responded and attempted to clarify his position in "Why Microsoft Loves Google Android, Take 2". While Richard deserves credit for being a good sport about my criticism, I still disagree with him. Here's why.

"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)...

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 then it’s not a Java Platform."

Monson-Haefel is confusing the Java platform and Java trademarks, and that confusion colors his whole perception of the "Android effect". According to Sun's trademark guidelines, open source FAQ, and brand guide, "Java" is a trademarked brand and logo that refers to a particular Sun product. The best a non-Sun product can be called is "Java Compatible" or "Java Powered". Since these are Sun trademarks as well, you have to follow Sun's rules to use them, which include passing the relevant TCKs (test suites). By the way, as far as I can tell the rules don't say anything about bytecodes or JVMs, just that the tests have to pass. Implementations are free to do things in different ways for efficiency or practicality, as long as the end result is the same.

Other phrases like "Java-based", "Java platform", or "Java technology" are not trademarked in and of themselves, so they can be used however you like as long as you follow the rules for respecting the Java trademark (such as putting the little "tm" on the first use).

The Open Handset Alliance doesn't call Android "Java", but programmers like myself, who don't care so much for legal hair-splitting, do. I also call facial tissues regardless of who made them "Kleenex", and I tell people to "Google" things on the internet. So sue me. Um, not really, that's a joke.

"[Android is] 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 is Richard's real beef with Android - that it wasn't specified through the JCP. Of course, there's no reason why it couldn't be. Google could submit a proposal tomorrow for a JSR (a standard proposal) that codifies the Android API. But they won't, at least not any time soon. It's not not because of any conspiracy against or disrespect of the JCP. It's simple practicality.

Android is brand spanking new. There is zero experience with it in the field. Many JCP watchers, including myself, feel that sometimes the JCP motto is "standardize first, see if it works later". Unfortunately that has lead to some standards that were, shall we say, less than perfect. EJB anyone? And once it's approved, you're stuck with it. Many prefer a more agile approach.

The best JSRs were submitted by people who came up with an API, implemented it, tested it, tweaked it and changed it based on lots of user experience. After a few iterations, they eventually submitted it as a proposed standard. A good example would be the Java concurrency library. Things like that just don't materialize out of a committee. My guess is, that's the path the Android APIs will take.

"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."

This part I can agree with. But instead of viewing it as "forcing" anyone to do something, I prefer to think of it as "leading". Android has the potential to un-fragment mobile Java technology and point the way to unifying the confusing editions and profiles that the JCP has saddled us with. Let's give it a chance and see what happens.

Editorial standards