The Java promise has been to reduce development and testing times. It also vows to provide a "write once, run anywhere" mechanism by adding itself as a layer between the operating system and the application. But Java has not eliminated the need to write platform-specific code. Consider the following: A developer still has to write custom platform-specific C/C++ code to build Java applications that can provide basic features, such as sharing data objects across applications and integrating directly with other native applications or with specific, useful hardware capabilities on the device. From this perspective, Java is no different than Microsoft, Symbian, Brew, Linux, or any other software layer upon which applications are created.
Furthermore, UBS Warburg made the following comment on Java in a May 2000 report: "Today, there is a fragmentation in the J2ME world as virtually every handset manufacturer has created its own proprietary Mobile Information Device Profiles (MIDP). This has resulted in incompatibility across applications and handsets.
But isn't Java 'write once, run anywhere?' The answer is both yes and no. While there is a common Java denominator, many manufacturers have written their own proprietary extensions to take full advantage of their devices. The result is a splintered standard. This, in turn, has led to the fragmented development of applications for each proprietary extension. What does that mean? Simply that not every J2ME application will run on every Java-enabled handset."
Now, think of the explosive success of "connected" applications on the desktop PC. This achievement was not accomplished because a tiny set of developers whipped out their C/C++ or Java compilers to build a custom application every time they needed access to data. On the contrary, it was driven by a common application run time like Internet Explorer, Netscape Navigator, etc. This approach solved all of the data-access and presentation-related computing problems. It also left the Web developer with the ability to both easily and quickly build and deploy HTML or ASP applications.
Something similar is needed on mobile devices. There should be a layer that allows existing Web developers to optimally leverage their skills by quickly building data applications. As it turns out, Java does not solve this problem any more than a C++ compiler and a set of BREW, Symbian, or Windows CE APIs.
The point is that developers aren't necessarily better off with Java. In fact, it's possible that developers might be worse off. They still have to write the specific code to target every proprietary MIDP upon which they want to deploy applications. They also need to write the code for accomplishing the items discussed above.
Maybe developers should consider a different approach—one that leverages the new class of next-generation smart devices. They could create their own native run-time layer or leverage someone else's that sits between the application and the operating layer (Smartphone, Pocket PC Phone Edition, Symbian, Java, Brew, Linux, etc.). This run-time layer can provide the built-in, rich application functionality upon which a classic Web developer has come to rely.
Some may argue that this isn't possible. They'll say that there isn't enough memory or processing power to do "heavy lifting" on the device itself. Sure, this was true one year ago. Today, however, carriers are shipping phones—and PDAs with phones—that are full-blown computers. And they're doing so at mainstream price points. These phones can free handcuffed developers so that they can create the rich, sophisticated applications for which they've longed. Developers are no longer imprisoned by technology limitations.