Developer Product Briefs
Get Creative on the Java ME Platform
The Java ME platform (formerly, J2ME) is six years old. Is it the right platform for your next mobile development project? Take a look at the state of Java ME and its CLDC/MIDP stack.
- By Michael Yuan
Get Creative on the Java ME Platform
Java ME continues to mature. Assess the platform, the standard APIs, the CLDC/MIDP stack, and device support for your needs.
by Michael Yuan
April 17, 2006
When Sun Microsystems introduced Java 2 Platform, Micro Edition (J2ME, which was renamed recently to Java ME) to the world in 2000, the promise was to bring Java's "write once, run anywhere" capability to the highly fragmented handheld-device market. Java ME is supposed to be the "one platform that rules all mobile phone manufacturers and carriers." It allows developers to focus their energy on creative work instead of tedious application porting across multiple devices, and it aims to create a mobile application marketplace where all applications compete on a level playing field.
After six years, Java ME has met with great success. It is now supported by all major mobile phone vendors and carriers. Today, more than one billion devices support Java ME out of the box. However, has Java ME fulfilled its "write once, run anywhere" promise?
Let's examine the current state of Java ME and the entire mobile application market. The aim here is to help you decide whether Java ME will fit your next project, and if it does, to focus on how to develop portable Java ME applications. Primarily we'll concentrate on mobile phone development on the Java ME platform, that is, the Common Limited Device Configuration (CLDC)/Mobile Information Device Profile (MIDP) stack including smartphones and PDA phones. Java ME has another stack, known as the Connected Device Profile (CDC) and Personal Profile (PP), to support larger personal digital assistants (PDAs) and set-top box devices. The CDC/PP stack has not been widely adopted and is not within the scope of this discussion.
The Java programming language is designed for cross-device portability. Java source code is compiled to a bytecode format that can be executed by the Java Virtual Machine (JVM). The JVM translates the bytecode to the native machine code for the target device at runtime (see the sidebar, "More on the JVM"). To run Java applications, a Java ME–compatible mobile phone must have the JVM preinstalled. Device manufacturers develop and preinstall JVMs for their devices, and, hence, insulate the application developer from the underlying device hardware and operation system, which are typically proprietary. In fact, many mobile phones on the market have completely closed operating systems, and Java ME is the only programming interface for those devices.
The Java language is only the basis of Java applications. Java ME is an application development platform built on top of the Java language. The most important components of the platform are the Java ME application programming interface (API) libraries. The APIs determine what kind of applications you can develop with Java ME. To enable the cross-device portability of applications, it is crucial to standardize those APIs.
In Java ME all standard APIs are developed from the ground up as an industry consensus through the Java Community Process (JCP). The JCP membership is open to all interested vendors and individuals. Almost all mobile phone manufacturers and carriers participate in the JCP. Every API is proposed by a JCP member as a Java specification request (JSR) and then developed by an expert group. The membership of the expert group is also open. At the time of this writing, there are 68 JSRs for the Java ME platform. Some of the most important JSRs are:
- JSR 30 for version 1.0 and JSR 139 for version 1.1 – The CLDC specifies the core language APIs for Java ME. For instance, it defines classes such as String and List, and it also specifies how the bytecode should be loaded into the JVM.
- JSR 37 for version 1.0, JSR 118 for version 2.0, and JSR 271 for version 3.0 – The MIDP specifies basic application-level APIs. It contains a UI widget library for small screens, a set of low-level APIs to draw directly on the screen and capture user input, a network API to send and receive data over the HTTP protocol, and a persistence API to store application data on the device memory. The MIDP also specifies the application lifecycle (that is, the MIDlet model for starting, pausing, and exiting the application); security model (that is, how to determine whether an application is trusted to access the network, and so on); and how the application should be deployed over the wireless network.
- JSR 120 for version 1.0 and JSR 205 for version 2.0 – The Wireless Messaging API (WMA) provides access to the device's Short Message Service (SMS) messaging functionalities. Using the WMA, the application can send SMS messages to any other device with a phone number. It can also receive incoming SMS messages. However, the WMA doesn't have access to the phone's native SMS inbox, and therefore cannot receive regular phone-to-phone SMS messages. It can only receive messages addressed to a special SMS port on the device. Most computer-based SMS tools and Internet-based SMS gateways allow you to send such messages with port numbers. In WMA version 2.0, you can also send and receive Multimedia Messaging Service (MMS) messages from the application.
- JSR 135 for version 1.0 – The Mobile Media API (MMAPI) provides access to the device's audio and video peripherals. You can use the API to play back audio or video clips. On some devices, you can also use the API to record voice and capture picture/video from the on-device camera.
To the Higher End
JSR 75 – The personal information manager (PIM) and file connection optional package provides access to the device's native PIM databases—for example, todo list, calendar items, and address book. This API also allows the application to save files to the device's native file system, as opposed to the simulated persistence store defined in MIDP.
JSR 172 – The Web services API provides a lightweight XML and SOAP parser library. You can develop mobile clients for SOAP Web services using this API.
JSR 184 – The Mobile 3D API is a lightweight 3D graphics library. It allows the application to create a virtual world and manipulate objects in that world. It is an important API for mobile game developers.
JSR 179 – The Location API allows the application to figure out the device's current location through an on-device, GPS receiver or through a query to the carrier's location server. When combined with mapping data—for example, Google Maps and Yahoo Maps—the location API allows us to develop powerful, location-based applications.
JSR 82 – The Bluetooth API provides access to the Bluetooth radio on the device. You can use the Bluetooth API to exchange data objects and/or simulate serial data links between nearby devices.
JSR 180 – The Session Initiation Protocol (SIP) API supports the SIP for network applications. SIP is important for push-based applications. It could also potentially open the possibility for Voice over Internet Protocol (VoIP) clients on mobile phones.
JSR 177 – The Security and Trust API provides access to the mobile phone's SIM card. The SIM card uniquely identifies the mobile subscriber account on the network. Through this API you can gain access to data and applications stored on the SIM card.
All Java ME-compatible mobile phones support at least CLDC and MIDP. Most devices on the market today support WMA and MMAPI as well. A mobile phone with CLDC, MIDP, WMA, and MMAPI support can be labeled as a Java Technology for Wireless Industry (JTWI)–compatible device. In addition, many high-end Java devices also support one or several of these optional APIs:
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.
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.
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.
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.