The optional APIs allow Java ME to scale from very low-end devices to high-end smartphones without falling into the trap of the lowest common denominator. Basic MIDP applications run on all Java ME devices. Applications designed for high-end devices can take advantage of the more capable hardware (for example, camera, GPS, and Bluetooth radio) through those optional APIs. Those applications probably wouldn't run on low-end devices (nor should you expect them to), but the point is that they are portable across similarly equipped devices from different vendors. With so many available APIs, Java ME is a comprehensive platform for developing all types of mobile phone applications, and yet it preserves the cross-device application portability as we can reasonably expect.

API Support by Device
For the APIs to be useful, the device manufacturers must implement and support them on the devices. One of the great successes of Java ME is its wide adoption among device vendors. Now, let's check out what Java ME APIs are supported on several popular mobile phones.

Sony Ericsson has a great line of Java phones. They have large heap memory space, large flash storage space, and no limits on the size of the Java application (JAR file). On a Sony Ericsson phone, the Java ME application can make outward HTTP connections through the WAP channel. Therefore, you need only a cheap WAP data plan (for example, the $5/month unlimited t-zones plan from T-Mobile) to use networked Java ME applications. That is a huge plus for many because phones from other vendors often require purchasing the full "Internet data plan" ($20/month for T-Mobile) to use the network (TCP/IP) in Java applications.

A midrange smartphone device like the K700 supports these Java ME APIs: CLDC 1.1, MIDP 2.0, Mobile 3D API, WMA, and MMAPI. The support for Java 3D on midrange devices (and even mass-market devices like the K300) is great for game developers too. However, it's also noteworthy that this device doesn't support the PIM and file connection API. It also lacks support for the Bluetooth API, although it does have Bluetooth radio.

A high-end Sony Ericsson phone like the W900 walkman phone is a truly powerful Java ME device. It supports all the APIs supported in the K700, plus Bluetooth API, PIM and file connection API, and Web services API. The Mobile 3D API support in W900 is backed by hardware acceleration. You can develop nice and fast 3D applications for the W900.

Nokia is the biggest mobile phone manufacturer in the world. It also sets the standard for mobile phone features and UIs. If you are developing a Java ME application, you will probably target a Nokia phone for prototype development at first. Nokia is a key member in the JCP, and it drives the development of many Java ME APIs.

A low to midrange Nokia S40 phone like the Nokia 6230 typically supports these APIs: CLDC 1.1, MIDP 2.0, WMA, MMAPI, and the Bluetooth API. A popular Nokia S60 smartphone like a Nokia 6680 supports CLDC 1.1, MIDP 2.0, WMA, MMAPI, Mobile 3D API, Bluetooth API, and the PIM and file connection API. A high-end Nokia S60 device like the E70 supports all of the aforementioned APIs plus the Web services API, Security and Trust API, Location API, and the SIP API.

Like Nokia, Motorola is an early supporter of Java ME and a key JCP member. However, Motorola phones' Java support has left a lot to be desired. For instance, Motorola's best selling RAZR V3 phone supports only CLDC 1.1, MIDP 2.0, WMA, MMAPI, and proprietary APIs to access the address book, file system, and the fancy LED lights on the phone. It's a pity that such a slick and popular phone doesn't support some of the more advanced and standard APIs.

Pros and Cons
Research In Motion's BlackBerry is a wildly popular e-mail device among enterprise users. The entire suite of software on the BlackBerry handset is built using Java. BlackBerry supports CLDC 1.1, MIDP 2.0, and an array of proprietary APIs to access the device's native e-mail client and other PIM databases. Those APIs are highly useful in constructing enterprise applications over BlackBerry's push messaging platform.

Palm Tungsten/Treo and Windows Mobile devices typically do not come with the JVM preinstalled. You can download and install third-party JVMs yourself to run Java applications on those devices. However, the third-party JVMs are typically limited to CLDC 1.1 and MIDP 2.0 support without any optional API package support.

While Java ME is a highly successful platform for mobile applications, several shortcomings that hinder its adoption over the past six years have been observed. For developers it is important to understand those shortcomings and how they might affect your development projects. Let's take a look at some potential solutions to those problems.

Device fragmentation refers to the reality that different devices support a different set of Java ME APIs and have different behaviors even under the same API. Fragmentation breaks application portability, and it is one of the biggest complaints from Java ME developers. However, it is important to understand that there is nothing wrong with fragmentation per se. Mobile devices are personal and specialized devices; different customers require different devices. It's a good thing that device manufacturers make a variety of devices to address the diverse market needs and differentiate themselves from competitors. In fact, this type of fragmentation is a sign of innovation. What's missing is a universal and standard best practice to help you work with fragmentation. Typical sources of fragmentation include different devices having different:

• Hardware add-ons and, hence, support different Java ME optional APIs – For instance, a low-end device without Bluetooth radio would not support the Bluetooth API.
• Priorities for their storage place and other computing resources – For instance, a device for the youth market probably supports the Mobile 3D API, but it is unlikely to support the Web services API.
• Form factors and different screen resolutions – They also support different data input methods (that is, keyboard, keypad, touch screen, voice recognition).
• Application sizes – Some devices can only install applications smaller than 100K, while others permit up to several MBs. They also support different amounts of heap memory space, persistent storage space, and maximum number of concurrent threads.
• Implementations of the same API – For instance, two devices might both implement the MMAPI, but one device supports capturing video clips and MP3 playback while the other supports only simple MIDI playback.
• JVM implementation bugs or behavior when the specification is vague – A major source of confusion comes from the multithread behavior of different devices. This behavior could be an issue when you have several threads updating the screen for animation and retrieving data from the back-end server. Different devices also have different behaviors when you try to free memory space by running a garbage collection.

Provider Assistance
Mobile application developers typically develop one application that runs well on a popular device, and then try to port the application to other devices in the same class. Device manufacturers can help by grouping similar devices together. For instance, Nokia groups all its devices into three developer platforms (Series 40, Series 60, and Series 80). Devices on the same platform have similar screen sizes and hardware capabilities, and support similar Java ME APIs. You need to develop your application for a representative device in each platform, and then only minor changes are required to port them to every device on the platform.

In the porting process, you typically need to optimize resource files (for example, images and sound clips) for the target device's screen, speaker, and memory space; add or remove functionalities based on the API availability on the target device; and provide source code–level workarounds for JVM bugs or other low-level JVM differences.

Several third-party solutions have been developed to address the device fragmentation problem. For instance, the NetBeans Mobility Pack (see Resources), which is a premier, free IDE for Java ME, supports precompile conditions embedded in Java code as comments. You can choose to include and/or exclude certain code blocks for each build target. It is a powerful way to introduce minor code changes between target devices.

By tweaking the build script, you can also choose what resource files to include for each build target. If you do not want to deal with the application porting issues by hand, Tira Wireless develops an automatic tool for porting and optimizing Java ME applications. The Tira Wireless Jump suite has a comprehensive database that documents differences among devices (see Resources). You can simply feed your "reference implementation" for a popular device into the Jump suite, and it will make changes automatically to the code and resource files to generate applications for the target device.

The second major shortcoming of Java ME is that it was originally designed without much thought about mobility. In fact, the CLDC/MIDP stack looks much like a miniature desktop environment with UI widgets tweaked to fit the small screen. Furthermore, because of the Java security model, Java ME applications do not have any access to device functionalities not exposed as Java APIs. As a result, most Java applications are limited in the CLDC/MIDP sandbox, and they are distinctly different from native applications on the device because of the lack of integration with the underlying system.

There is no integration with the device's native applications (for example, the messaging client, the video recorder, the music player, and the screen saver), and there is little integration with low-level hardware features (for example, access to the device serial number, cell ID, and so on). The CLDC/MIDP sandbox is probably OK for simple, form-based business applications or simple games ported from the PC world. However, the problem is that there is only limited need for "desktop replacement" mobile applications. Many users already use laptop PCs or tablet PCs for this type of application. Plus, those Java ME applications represent only incremental improvements over WAP browser and Flash-based applications. They aren't all that exciting, and therefore the adoption rate is low.

Wish List
What mobile application users and developers really want are applications that can truly take advantage of mobility features that are available only on mobile phones. We want applications that integrate tightly with the underlying phone platform and behave like native applications.

For instance, here are several feature examples that would be great to have in Java ME applications or games: the ability to make, receive, and manage voice calls; the ability to make use of and manage users' personal data on the phone (for example, address book, calendar, photos, and ringtones); an idle screen or screen saver to run in the background while processing user input and SMS or Bluetooth for responding to incoming messages; the ability to uniquely identify the user through IMEI number, subscriber number, or even digital certificate; location sensitivity; and camera-based applications.

Of course, the Java ME optional API packages are designed to provide Java applications more access to the underlying platform. For instance, the PIM API allows access to the PIM database (for example, address book) maintained by native applications, the file connection API provides access to the photo and music folders on the device, and the Location API enables location-based applications.

However, some important features are simply not supported in current APIs. For instance, there is no Java ME API to support voice calls, which is by far the biggest application for mobile phones. Even for features that are supported in current APIs, the JVM implementation often leaves a lot to be desired. For instance, the photos captured from the MMAPI typically have much lower quality than photos captured from the native camera application.

To make Java ME a better mobile application development platform, we need to push out more optional API packages and get them implemented by phone manufacturers, which leads to the next weakness in Java ME.

As mentioned previously, all the Java ME APIs are collaboratively designed by the JCP. Many JCP members compete with one another. The JCP process certainly helps those vendors reach a consensus that they can all support. However, this design-by-committee approach is also slow, especially when some vendors have political agendas. For instance, it took the JCP more than three years to develop the PIM and File Connection optional packages in Java ME, which is a long time in the world of mobile applications. That delay has resulted in the situation today in which the Java environment on the majority of Java ME devices has no integration with the most popular native applications.

A potential solution for this problem is to encourage mobile phone vendors to develop and support proprietary Java APIs on their devices if no standard APIs for the same functionalities are available. Nokia and Motorola have used this proprietary API approach in the early days of Java ME out of necessity. BlackBerry is still using this approach today with good results. Applications developed against those proprietary APIs would not be portable. However, that would give Java developers a way to write advanced applications for this particular device (or family of devices) if they choose to. In fact, the proprietary API can also act as a testing ground for JCP APIs. If those APIs are proven successful, the vendors can then work together to make it a standard.

About the Author
Michael Yuan, Ph.D., is a developer, speaker, and author specializing in end-to-end enterprise and mobile solutions. Michael is the author of three mobile technology books including Nokia Smartphone Hacks (O'Reilly Media Inc., 2005); Enterprise J2ME (Prentice Hall PTR, 2003); and Developing Scalable Applications for Nokia Series 40 Devices (Addison-Wesley Professional, 2004). He has served as an expert group member in several Java Specification Requests (JSRs), and he works currently for JBoss Inc.