Richard Monson-Haefel responds, still gets it wrong

Richard Monson-Haefel responds, still gets it wrong

Summary: 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.

SHARE:

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.

Topics: Open Source, Android, Google, Software Development

Ed Burnette

About Ed Burnette

Ed Burnette is a software industry veteran with more than 25 years of experience as a programmer, author, and speaker. He has written numerous technical articles and books, most recently "Hello, Android: Introducing Google's Mobile Development Platform" from the Pragmatic Programmers.

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.

Talkback

4 comments
Log in or register to join the discussion
  • So, maybe in 2 years, they will give it a name and standardize it, AFTER

    it has been banged on and everybody has had a chance to criticize every little detail. I am sure that Sun will be right behind Google on this one.

    And, talking about Java and Google, we also need a special JVM with some very special sand-boxing for web applications, that is part of Gears, and eventually part of FireFox. I would love for that to get driven the same way.

    Come on Google, add a custom JVM to Gears.
    DonnieBoy
  • RE: Richard Monson-Haefel responds, still gets it wrong

    Initially, Richard seems to be trying to back off from his previous claims.

    [i]I???m just saying that Android is a threat to Java standards.[/i]

    Generally, I think he makes a good effort to provide clarity and a precise thesis, even using the word "thesis" to distinguish it from related claims and supporting facts!

    [i]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.[/i]

    It's a valiant effort, but the revised thesis also strikes me as tenuous.

    Google's smartphone, which uses Java, is major enough to [u]affect[/u] Java standards, I'd agree, but that probably wouldn't be interesting enough to argue. Perhaps, not even to read. To call Android a threat, though, implies more to me than the obvious fact that important, large projects using Java -- as Google hopes Android will be -- are somehow a danger to the existence of [u]any[/u] Java standards. That would be a stupid claim, and to his credit, Monson-Haefel hasn't actually made that claim, but what does he mean, exactly, by a "threat to Java standards"? The "write once, run anywhere" slogan seems to be the Achilles Heel Monson-Haefel is targeting. But that slogan was introduced within a client-server model, without smartphones & portable mp3 players. If Java is still useful, even with adaptations, I consider that a point in favor of Java's versatility, not against.

    [i]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.[/i]

    I'll agree that it's a fork. I don't agree that such constitutes a "threat."

    [i]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.[/i]

    Ed has described that this is already under way, and has been for some time. Android seems to be a part of that process, even a community contributor to the JCP, not a threat.

    [i]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.[/i]

    Competent programmers should be able to improvise. Those working on a mass-production mobile communications device, especially, should be able to figure out whether they need A, or B, or some hybrid or makeshift solution.

    [i]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.[/i]

    If there is a "community process," it would be about defining standards as much as enforcing them. If [u]re-defining[/u] is inherently a "threat to Java standards," why have a "process"? Why not, in that case, just have "community standards"? As long as they are more rigorous than "I know it when I see it," Java developers should be OK.

    [i]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.[/i]

    Time will tell, but the computing industry in general has survived change at the rate of Moore's "Law" in certain realms over sustained periods. I think the Java platform can survive a new mobile phone programmed in some new fork of Java.
    Absolutely
  • Nice Try - No cigar

    Write once, Run everywhere

    That's indivisible, we never had it before -
    the nearest was the c library running console
    applications in the 70's

    Implementing any API you feel like sounds
    attractive, but everyone who tries to use the
    resulting apps on any platform other than exact
    one the original was written for will suffer
    for it.

    You have a right to debate anything, but in
    fact we know the truth of this argument.

    I'm sure you already know, but if you don't,
    check out "Embrace, Extend and Extinguish" -
    http://en.wikipedia.org/wiki/Embrace,_extend_an
    d_extinguish
    tomm174@...
  • RE: Richard Monson-Haefel responds, still gets it wrong

    "Android has the potential to un-fragment mobile Java technology"

    Android and un-fragment in the same sentence... ;)?
    Panajev