Application Platform Strategies Blog

Are PDAs dead? Not at all and here's why...

Blogger: Richard Monson-Haefel

It's easy to think of Personal Digital Assistants (PDAs) as a dead technology. After all, don't most smartphones, and even basic feature phones, include address books, contact lists, calendars, and such? Why buy a PDA which has no phone when you get a phone that has a PDA built right in?  That was my thinking until this last week when I had a fascinating conversation with Socket Mobile, a company that has been manufacturing peripherals for PDAs for about a decade.

It turns out there is a market for PDAs that do not offer phone capabilities - especially ones that are hardier than consumer devices but not as bulky as industrials devices.  Nurses use these types of devices while working with patients, retailers use them while taking inventory of stock, wait staff in restaurants use them to take orders, researchers use them to enter measurements and field data, and the hospitality industry uses them in their house keeping efforts. That's only a few really obvious examples - there are lots more. And in these types of situations you want the device to be portable and locally networked, but you don't want it be a mobile phone.  Can you imagine your waitress answering personal calls while taking your order? That's an extreme example, but the point is there are some jobs where having access to a mobile phone is not necessary or even desired but having a mobile device is. That's the PDA market that still exists today. (read more ...)

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!

Why Microsoft Loves Google's Android

Blogger: Richard Monson-Haefel

Note: due to inconsistent use of terminology this blog post can be confusing. It's been replaced with a new entry "Why Microsoft Love Google Android, Take 2".  It's recommended that you read that post rather than this one.

You won't hear Microsoft say this out loud, but secretly they are celebrating Google's contribution of the Android mobile phone platform to the Open Handset Alliance - at least they aught to be. Android is perhaps the best thing to happen to Microsoft since they won the browser wars in the 1990’s.  And given Verizon’s announcement yesterday that they will be opening up their network to any device and operating system that meets a "minimum technical standard" it seems that Android may have legs even if Google doesn't secure the 700 MHz spectrum.

Microsoft's biggest competitor in the software development industry has been, for the past 12 years, Sun Microsystems' Java Platform.  Starting in the mid to late 1990's Java began to gain mind share among developers in every area in which Microsoft has an interest. Today, with over 6 million developers (according to Sun) Java clearly dominates the software development industry.  Point in fact, Microsoft had to completely revamp their software development platform in 2000 to mimic the Java platform in order to complete; enter Microsoft .NET.  While Microsoft .NET has been extremely successful at winning back a portion of the developer community from the Java platform, Java has remained the darling of the enterprise and perhaps the most successful software development platform in the history of computing. Microsoft really doesn't like the Java platform very much. Java is Microsoft's biggest competitor in software development and is arguably the platform to beat. 

The Java platform and its standardization process are not perfect. A series of missteps by Sun Microsystems and the Java Community Processes (JCP) have contributed to the growing success of Microsoft .NET. The JCP which defines the Java standards has allowed the enterprise platform, Java EE, to become unbearably complex and has created an ecosystem for its mobile platform, Java ME, which is terribly fragmented despite its overwhelming penetration (8 out of 10 phones ship with Java). The foundational platform, Java SE, however has remained a strong competitor and has given up very little ground to Microsoft, but all that is about to change with the introduction of Google's Android mobile platform.

To put it bluntly: Android as it is currently defined is a fork of the Java ME 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. 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. This was first pointed out by Stefano Mazzocchi in his November 12th blog entry entitled "Dalvik: how Google routed around Sun's IP-based licensing restrictions on Java ME". Stefano missed the fact that Android does not properly implement the CDC or CLDC Java ME APIs (a minimum requirement for Java ME conformance) - but kudos to him for being the first to report on the fork. The fork has since been picked up in the blogsphere by others here, here and elsewhere.

The forking of Java is good news for Microsoft for a couple of reasons. First, 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.  If Android, as it’s currently defined, is successful then Java will no longer be consistently implemented at a fundamental level.

Microsoft offers an excellent mobile platform of its own, Windows Mobile and Microsoft .NET Compact Framework. It's proprietary, that's true, but it’s consistently implemented and extremely powerful platform for developing Rich Mobile Applications (RMAs).  In comparison, Java ME is a standard that has a wealth of functionality and is supported by dozens of vendors, but its implemented inconsistently across mobile devices making it extremely difficult to develop applications that will "write once, run anywhere". If Android succeeds (time will tell) then Java on mobile devices will loose its hold on the market. Android may win, but Java ME will loose.  If I was in the Windows Mobile and .NET CF marketing department I would be popping the cork on a huge bottle of champagne the day Android is released. It's the best thing that could have happened to Microsoft's mobile platform.

OK, so if the Java mobile platform will falter because of the introduction Android, how does that impact Java SE? After all, Java SE is used for desktop and server-side development. How is that threatened by a mobile platform? Good question. Here's why: Sun has been moving toward unifying the Java ME and Java SE platforms for a while now.  This was pointed out in an excellent analysis by Caroline Gabriel of Rethink Research. As part of the evidence for her argument Caroline references a quote from James Gosling the "father of Java” in a CNET interview just last month.

"We're trying to converge everything to the Java SE specification. Cell phones and TV set-top boxes are growing up," Gosling said at a Java media event here Wednesday. "That convergence is going to take years."      

But don't take James Gosling's word for 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.  After all, Java ME was developed for "constrained devices" with limited memory and processing power. However, as technology advances that label no longer applies to mobile phones in general. Smartphones are becoming powerful, if smaller, computers with complete operating systems, lots of processing power and plenty of memory. The era when mobile phones are simple appliances is coming to an end - mobile phones are becoming a complete computing platform.

The reason a phase out of Java ME and the expansion of Java SE to mobile devices is so important to Sun Microsystems, is that it meets Sun’s original goal for Java. It establishes a single platform for all computing devices. It makes excellent sense and improves the argument that Java is a standard consistently implemented across computing platforms. Sadly, however, by the time that happens Android may have already Balkanized the mobile Java community into Java ME and Android camps.  The “one platform to bind them all” party may be over before it gets started.

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.  You tell people that the skills your enterprise developers gain writing desktop and server-side applications will translate directly to the mobile platform. 

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.  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?  You'll find the answer to that question in historical records when Sun Microsystems successfully stopped Microsoft from adding proprietary extensions to the Java platform in the 1990's.  As pointed out by Maureen O'Gara there is some irony here. 

“The sweet irony is that this greatest threat to Java since Microsoft should come from Google CEO Eric Schmidt, the guy who originally led Java development at Sun and signed the contract with Microsoft, leading to the Java wars.”

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" standardization, is effectively lost.

Verizon opens up its network. Wow!

Blogger: Richard Monson-Haefel

Verizon announced yesterday that they will be opening up their network to any device or operating system that meets a "minimum technical standard" starting in the second half of next year.  This is fantastic news provided it comes true - its also a huge boost to the potential of the Android platform because Google will not need to acquire the 700 MHz spectrum to make it succeed (although they still have an API fragmentation problem not to mention the forking of Java). Like many I'm cautiously optimistic. A great analysis as to why we should be cautiously optimistic is provided by Om Malik in his blog entry "Why Verizon Went Open and What it Means".

Mobile Application Development

Blogger: Richard Monson-Haefel

Since January 2007 I've been spending most of my time researching and writing about application development on smart phones.  I've had the opportunity to research and write about Ajax development on mobile devices, Java ME, Adobe Flash Lite and most recently Microsoft .NET Compact Framework.  If you are a client you will have already received a notification, earlier this year, about an overview I wrote called "Rich Mobile Application Platforms for the Enterprise ". That document is just the tip of the iceberg. 

Next year we will be publishing all of my findings including an in-depth market landscape and four product reviews on mobile application development for the enterprise - I also plan to update the overview I wrote earlier. In total there will be six more documents that will be published in Q1/Q2 of 2008 on mobile application development frameworks and toolkits.   This will provide Burton Group's Application Platform Strategies service with a strong start on mobile application development for the enterprise.

During my research I've read an enormous amount of documentation and spoke to dozens of vendors, developers, and end-users. It's been a hoot and I learned a lot.  I wanted to call attention to a specific resource that I believe stands above the rest, a book on mobile application development called,  “Microsoft Mobile Development Handbook” (Microsoft Press 2007) by Andy Wigley, Daniel Moth, and Peter Foot.

In a nutshell the book is one of the best programming books I’ve read in a long time. In fact, I give it my highest recommendation. .NET Compact Framework is a nice piece of work and this book will help you appreciate all of its capabilities and how all the parts fit together. At about $70.00 a pop it’s not cheap and it can be difficult to find – it was sold out in every bookstore in
Minneapolis save one – but its well worth the price and effort. (You can get it at Amazon.com for about $45.00 at this time.) 

If you are thinking of developing mobile applications and are considering .NET Compact Framework, I recommend you buy a copy of this book.