Why Microsoft hates Google's Android

Why Microsoft hates Google's Android

Summary: Richard Monson-Haefel, an analyst at the Burton group, just posted a sarcastic and inaccurate analysis of Android called "Why Microsoft Loves Google's Android". Perhaps he feels he's doing Sun and the JCP a favor by attacking Android, but he's not. In fact, he has managed to get things twisted around so badly I felt compelled to write a rebuttal. I hardly know where to begin...

SHARE:

Richard Monson-Haefel, an analyst at the Burton group, just posted a sarcastic and inaccurate analysis of Android on the company's blog. In his article, called "Why Microsoft Loves Google's Android", Monson-Haefel claims that Microsoft should be "secretly celebrating" Google's introduction of Android. "Android is perhaps the best thing to happen to Microsoft since they won the browser wars in the 1990’s," he writes.

[ READ: Richard Monson-Haefel responds, still gets it wrong ]

Monson-Haefel, who proclaims himself "one of the world's leading authorities on Enterprise JavaBeans (EJBs)", served on the JCP Executive Committee which oversees Java specifications. Perhaps with this background, he feels he's doing Sun and the JCP a favor by attacking Android, but he's not. In fact, he has managed to get things twisted around so badly I felt compelled to write this rebuttal. I hardly know where to begin. For example he writes:

"To put it bluntly: Android as it is currently defined is a fork of the Java ME [micro edition] platform. Android is similar to the Java ME, but it's a non-conformant implementation. Android is not compliant with Java ME nor is it compliant with Java SE [standard edition]. In fact, it’s not really Java. Although it uses the Java programming language, the core APIs and the virtual machine are not consistent with the Java ME or SE platform - it’s a fork."

Right up front he's invoked the dreaded f-word of open source. Even if Android were a fork, as I've pointed out before forks aren't necessarily bad. But Android is no fork. Earlier in the article Monson-Haefel says that Java ME is "terribly fragmented". You can't fork something that is already fragmented.

Furthermore, Android does not have a line of code in common with Sun's Java ME. Being a derivative of or improvement upon an earlier version is one of the prerequisites of a fork. And besides, he says that "it's not really Java". How can something that is not Java be a fork of Java? It can't. You don't hear him calling Microsoft .NET a fork of Java, even though under his logic maybe it should be.

"From a marketing perspective the Java platform's greatest strength is standardization and multi-vendor (e.g. IBM, Oracle, SAP, etc.) support. In comparison, Microsoft .NET is a portrayed as a proprietary platform that locks-in organizations to the Microsoft platform. That's the marketing message which has been used by Java proponents for a decade and it has been extremely successful. But now, with the introduction of Android, the solidarity around the Java platform could crumble."

How in the world can you look at the 30+ vendors lined up for the Open Handset Alliance and say that is not "multi-vendor"? And speaking of solidarity around the Java platform, take a look at the Sun/IBM relationship and you'll see it's pretty crumbly already. Some see this is a weakness, but others as a strength (innovation through competition).

"If Android, as it’s currently defined, is successful then Java will no longer be consistently implemented at a fundamental level. ... Java ME is a standard that has a wealth of functionality and is supported by dozens of vendors, but it's implemented inconsistently across mobile devices."

(emphasis mine) I wonder if saying two completely contradictory things in the same article is some kind of requirement for being a successful analyst. That way, at least half of what you say will come true.

"If Android succeeds then Java on mobile devices will loose (sic) its hold on the market. Android may win, but Java ME will loose."

First of all the Android programming model is fundamentally Java. It's a subset of Java SE with some mobile and user interface stuff added on (with Linux underneath). Technical distinctions that say Android is not Java are just splitting hairs. Android doesn't claim to be Java but even Sun CEO Jonathan Schwartz calls it Java.

Now, Java ME is also a subset of Java SE with some mobile and UI stuff added. A much more restricted subset, and a much more brain dead UI, I have to say. If Android supplants Java ME, this does not harm the Java community. Especially, as Monson-Haefel argues in the next couple of paragraphs, if:

"Sun has been moving toward unifying the Java ME and Java SE platforms for a while now. ... Just take a look at JavaFX Mobile, which Sun Microsystems announced earlier this year. It's based on the full Java SE platform, not Java ME. In a nutshell Sun Microsystems isn't betting on Java ME for the long-haul, they are betting on Java SE."

Ok, so we're supposed to be upset that Android may supplant Java ME, but a slow transition from ME to SE has been underway for a while now. The Android VM and API is far closer to Java SE, so... what was the problem again?

"How do you sell people on Java? You tell them that it’s a standard used across mobile, desktop, and server applications. You tell people that the skills your enterprise developers gain writing desktop and server-side applications will translate directly to the mobile platform."

You mean like EJBs? I didn't think so. Every platform and API has its place. If you look at all the APIs ever approved by the JCP, it's incredibly huge. Only a tiny fraction of it is applicable on a mobile platform. Instead of splintering Java into ME and SE universes (which were quite different), Google had the smart idea of trimming a little off of SE and adding some things SE doesn't have. Mobile, desktop, and server programming are thus much closer under this model.

"Unfortunately Android undoes all that. It tells the industry that Java is not consistent across computing platforms and that using the Java language, but not the APIs or virtual machine is just fine as long as the end result is a workable solution."

Ah, well we wouldn't want to focus on pragmatic and workable solutions, now would we?

"That leads us to the assumption that if it works for the mobile industry then why not the desktop or the server-side? Why can't other vendors introduce platforms that use the Java programming language and some of the Java APIs, but is otherwise inconsistent with the Java platform? What's the harm of IBM or Oracle having their own version of Java as long as it works?"

I don't know where Mr. Monson-Haefel has been for the last few years but this has already happened. IBM has J9, BEA has JRockit, and Apache has Harmony, to name a few. If companies want to use the Java trademark, though, they have to pass an extremely rigorous compatibility suite created by Sun.

"Java's greatest strength today is uniformity and ubiquity. Take away uniformity and you end up with many different kinds of Java and so there is no real ubiquity. Take away ubiquity and there is very little incentive to choose the Java platform over other options like Microsoft .NET. In fact, Microsoft .NET starts looking a lot more attractive because it is consistently implemented; not Balkanized. If .NET is just as powerful as Java, why choose a solution such as Java that is inconsistently implemented across vendors? The strongest marketing asset that Java has today, 'write once, run anywhere (WORA)' standardization, is effectively lost."

If Mr. Monson-Haefel had done a little research first before making blanket statements like this, he would know that Microsoft .NET Compact Framework is not the same as regular .NET. Compared to the desktop version, the Compact Framework has some things trimmed out and some other things added in that are specific to mobile devices. Sound familiar? Android takes the exact same approach.

There is still one overall "Java platform", regardless of what the language on top is (Java, JRuby, Groovy, etc.) or the particular flavors of the API (ME, SE, EE, GWT, Android), how the code is compiled and run (JIT, AOT), or even what the bytecodes look like. The Java platform is much bigger than any one hardware platform or vendor.

Android represents an incredibly positive new injection of resources and excitement into the Java, Linux, and open source communities. It's unfortunate that a respected analyst like Mr. Monson-Haefel fails to recognize this fact.

Related articles:

Topics: Android, Google, IBM, Microsoft, Open Source, 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

24 comments
Log in or register to join the discussion
  • Who hates Android? (Not me.)

    Indeed, JavaME already is highly fragmented, so what does Monson-Haefel want to protect? I really wonder what the purpose of his posting is. Strengthen Java? Strengthen Microsoft? Create FUD around Android? Why?

    As we have seen with Eclipse, competition and open source are great for progress and adoption. Just like IBM has created the strongest and liveliest development platform ever with Eclipse, I see Google doing the same with Android. Android really is a great chance for a new mobile standard. If we are lucky, IBM and Google will fix all the mistakes that Sun has made in the past.

    Good article, Ed!
    CarlRosenberger
    • Well said Ed

      The guy who wrote the original article is obviously a washed up dinosaur.
      fr0thy
  • Thats a simple answer....

    It will be competition in the smart phone arena, currently there is no real competition, Palm has not been keeping up and the iPhone is available only to one carrier also most of the BlackBerrys do not cut it either.
    mrOSX
    • Hopefully Palm will eventually get new OS released...

      I'm crossing my fingers that Palm will finally get their Linux based OS released, so that they can rejoin the competition. I would also add WinMo to your list of mobile OS's that don't really cut it. It is still too sluggish for my taste, and WinMo 6 has memory leak issues right now. If that iPhone with OS X were to enter into more carriers, including CDMA, and add some features that true PDA phones offer, that would wake the competition up for sure.
      Aragorn_z
  • RE: Why Microsoft hates Google's Android

    Android must fail. Why? All google applications share one common feature -- they all look like *ass*, due to their *IX background, they have no appreciation for a functional UI. No one would even dream of using the dysfunctional UI that the google guys will dream of.
    tshinder@...
    • [i]Will[/i] dream of? You need to do your homework.

      The UI is already done, is extremely usable and can be demonstrated through the emulator that comes with the dev kit.

      http://www.youtube.com/watch?v=_avwGFsv60U&feature=related

      In future, I'd suggest you save face and keep your yap shut when you don't know squat about a subject.
      odubtaig
  • Virtual Machines

    Oddly enough, this is one of those cases where both of you could be right. It has to do with how interpreted languages work.

    Java is a programming language, and it compiles down to bytecode that is interpreted by a runtime engine (JRE). Sun can call it Java because the programming language itself is Java. Monson-Haefel may be correct in that the bytecode and runtime engine may not run on the JRE and therefore are not "Java" (Sun generally ties the JRE and language together). For that matter, Java could even be compiled down to assembly, but it is unlikely this will ever be done, even on Android.

    .NET is similar - .NET itself is like the JRE in Java. The programming language for .NET varies, however - it could be Visual Basic or C# or J# or whatever (heck, you could have Java .NET if such a language existed). Java could be done the same way, it just isn't.

    For illustration
    traditional programming:
    code--compile-->machine code

    interpreter
    code--compile-->bytecode--interpret-->machine code

    Obviously the extra step for an interpreter means that it is usually slower ("just in time" compilers and precompiling at the interpreter stage that can give them near-compiled speed). Interpreters, however, make it easier to move programs onto different hardware since they all see the same bytecode (and usually have a defined endian-ness and hardware abstraction layer), whereas assembly code depends entirely on the chip it's running on. That means it should be write once, run anywhere (as Sun's per slogan for Java), but may mean write once, test everywhere (which is the reality).
    Clewin
    • GCJ already compiles to machine code.

      http://gcc.gnu.org/java/

      Compiles code to bytecode or machine code and bytecode to machine code.
      odubtaig
    • Don't say 'interpreted language'

      Interpretation is just an implementation choice not a property of a language. I could write an interpreter for the C language, does that make C an interpreted language? No.

      Both Java-the-platform and .NET-the-platform support multiple languages. Both can run Python and Ruby programs for example. Both compile the high level language down to an intermediate portable form ("bytecodes" and "MSIL" respectively).

      You could interpret the intermediate form (think of fetching the operation code and having a big switch statement) but that's too slow so both have modern implementations that then translate that portable form into native assembly instructions. Android adds an extra step where it translates from bytecodes into another intermediate portable form but this doesn't matter to the programmer.

      Intermediate forms are nothing new. GCC works that way, as does the MS C++ compiler. In the C compiler I worked on, compilation was split into two phases. Phase 1 compiled C into the intermediate language, and Phase 2 compiled the intermediate language into assembler code. The only difference between this and the Java/.NET model is when you do the second phase. By delaying it as long as possible the systems developer can take advantage of extra knowledge to do global optimization or customizing the code generation for the particular make and model of computer the code needs to run on (think Barcelona, SSE, etc.).
      Ed Burnette
  • The qualifications for the position

    of ?one of the world?s leading authorities on Enterprise JavaBeans (EJBs)? do not seem to be set so high as to constitute an undue hinder to anyone who might aspire to the title....

    Henri
    mhenriday
  • MS hates the 'E' word as much as the 'L' word

    Take a brief look at Android and [url=http://code.google.com/android/intro/installing.html#developmentrequirements]Installing the SDK[/url] and it doesn't take long to realize that Eclipse is pivotal to Android development (using Android ADT plugin).

    Eclipse makes O/S agnostic Java applications possible, among other niceties and in fact makes writing Java applications more viable and marketable.

    Eclipse is perhaps the most serious threat to .NET, which MS hates perhaps more so than Linux.

    Thanks
    D T Schmitz
  • RE: Why Microsoft hates Google's Android

    Interesting rebuttal. I promise a response this post but I have a deadline tomorrow so it will have to wait ... looking forward to more debate on the subject!
    rmonson
  • Why Microsoft loves Google Android

    Interesting rebuttal. I promise a response this post but I have a deadline tomorrow so it will have to wait ... looking forward to more debate on the subject!
    rmonson
    • "Tomorrow" has come & gone.

      You haven't rebutted.

      Assuming you actually are the author of the original article Ed critiqued, I think your basic error is that you write of programming languages & runtime environments as ends in themselves rather than the means to create simple controls over relatively complex machinery. What matters to a good programmer is not that programming in Java is everywhere uniform, but that the differences in programming Java on Project A vs. Project B are predictable, and even your own article does not convince me that is a problem in the context of Android. The differences you describe do not imply the monumental difficulties you conclude.

      [i]Assuming the demise of Java ME as a standard platform for mobile development is nearing and that Java SE will take its place, the question of a consistent platform across all computing devices becomes even more important. How do you sell people on Java? You tell them that it?s a standard used across mobile, desktop, and server applications.[/i]

      The functions that smart phones perform are sufficiently standardized already that end users won't notice the difference, and as I implied above, programmers will continue to enjoy the challenge and profit of writing new software for different hardware. The end user only needs the Java ME/Java SE programmers' output to make a final product that sends & receives phone calls & e-mails, & surfs the web. The programmer only needs to know, for any given project, the required outcome, the rules of his programming language, and a (relatively small) body of knowledge of the system or systems with which his project (here, smart phones) must interact. A well-defined summary of the difference between the rules for two similar languages or environments goes a long way.

      [i]You tell people that the skills your enterprise developers gain writing desktop and server-side applications will translate directly to the mobile platform.[/i]

      For brainless recording devices, that requires absolute uniformity. For thinking people, that only means similarities, and good, easily found documentation of the differences.

      [i]Java's greatest strength today is uniformity and ubiquity. Take away uniformity and you end up with many different kinds of Java and so there is no real ubiquity.[/i]

      Versatility is a strength, and I think you've overlooked it entirely in your analysis. Versatility also does not require absolute uniformity; in fact, those two traits tend to be contrary. Minimizing the cost in uniformity to achieve the desired versatility is the challenge for both corporations, in achieving their desired ubiquity.
      Absolutely
      • round 2

        http://blogs.zdnet.com/Burnette/?p=476&tag=nl.e027
        Absolutely
  • Lame Title, good blog. Misleading

    It was a good blog but please have the decency to actually use a title that reflects the story. The discussion of Android and Java is lost in the sensationalism of trying to make it sound like there is some Google / Microsoft rivalry happening when in fact that's not what the blog is about at all.
    GeiselS
    • Re: Lame title

      The title was intended to be the opposite of Richard Monson-Haefel's title. I thought of calling it "Android's Google loves Microsoft, why?" but didn't think anybody would get it. Might make a good haiku though.

      For another example of this brilliant literary technique (that's a joke) compare http://blogs.zdnet.com/Burnette/?p=332 with http://blogs.zdnet.com/BTL/?p=5348 , or compare http://blogs.zdnet.com/Burnette/index.php?p=189 with http://www.windowsitpro.com/Article/ArticleID/93992/93992.html .
      Ed Burnette
      • Good title

        I got it Ed.
        It does also make reflection on the passionate dislike MS has for Google, and you tempered it all with another thoughtful article.
        dfolk
  • RE: Why Microsoft hates Google's Android

    Who the 'fork' still listens to Moron, sorry Monson-
    Haefel?
    csaager
  • RE: Why Microsoft hates Google's Android

    Perhaps the author should look a little more closely at his stance. To me it (very nearly) reflects the same level of bias as the original article. The real Java issue with Android is the attempt to create a Java run time environment that isn't Java. This adds to the fragmentation that JME developers have to consider.

    However, on the pragmatic side the overall penetration of 'open' operating systems on mobiles will be a fraction of the total mobile sales. So good old JME and MIDP 2,3,..,n will prevail.
    ipannell@...