The J2ME alphabet soup
On the surface, this would seem to be a good thing for developers hoping to leverage mobile computing for an application. However, the term "mobile devices" covers quite a bit of territory, including the traditional PDA, so-called smart phones, pagers, and even GPS units—all of which represent very different hardware configurations. Likewise, the marketplace for these devices is fragmented to the point that expecting compatibility between two devices from the same vendor, let alone devices from different vendors, is foolish in many cases.
Trying to serve this motley crew of devices with a single one-size-fits-all
development platform would be impossible. So J2ME defines two types of
specifications that operate hand in hand to provide a mobile Java platform: configurations and profiles. A veritable alphabet
soup of configuration and profile specifications exists. Let's take a look at a
few of them.
Configurations galore
J2ME handles the vastly different hardware capabilities of mobile devices
through an abstraction known as a configuration. A J2ME configuration defines
the virtual machine and low-level API that is made available on a particular
device, providing the development foundation. Two primary configurations are in
use, Connected Device
Configuration (CDC) and Connected Limited Device
Configuration (CLDC).
Connected Device Configuration
CDC is applicable for devices with relatively large amounts of memory and powerful processors. The CDC specification calls for a memory-optimized virtual machine, called the CVM that offers the same features as the standard JVM. According to Sun's documentation, the CDC is meant for higher-end devices such as newer PDAs, smart communication devices, and set-top TV boxes. To be supported by CDC, a device must have, at a minimum:
The CDC requirements would make for an expensive mobile phone, IR scanner, or the like. The CLDC is meant for those lesser, and less expensive, devices that can't meet the requirements of the CDC.
CLDC uses a very stripped-down virtual machine designed to run in a low-memory environment. The reference implementation of that JVM is known as KVM, since its size is measured in kilobytes. CLDC is meant for devices with the following:
As you'd expect from the draconian memory limitations, the KVM lacks some features provided by the full JVM, which might require you to change your programming style. Some of the things the KVM trades for such a low memory requirement are floating-point math, reflection, and support for class finalizers. Developers using the CLDC will also have to pre-verify their source code after compilation using a verifier tool supplied with the J2ME development kit.
You've got a great profile
If a configuration provides the foundation for an application, a profile provides the framework. Profiles define the full set of API classes that will be available to a J2ME application and are built specifically for a given configuration. Sun has made two reference J2ME profiles available: the Foundation and the Mobile Information Device Profile (MIDP).
The Foundation profile is intended specifically for the CDC configuration and therefore has the luxury of a virtual machine that's almost identical to the standard virtual machine. This means that developers using the Foundation profile have access to a full implementation of J2SE's feature set.
The MIDP, along with the low-powered CLDC configuration, provides the Java platform you'll likely use when developing applications for today's mobile devices. MIDP supports a limited subset of the J2SE class library and defines custom user interface and input/output classes for use on a CLDC configuration.
Write once, run anywhere?
What about compatibility? Can a J2SE application run on a J2ME platform? The answer depends largely on the configuration and profile in use. J2SE code should run with little or no modification using the CDC along with the Foundation profile. However, as I've discussed here, CLDC and the MIDP profile provide only a very limited set of functionality because of the limited host hardware that's available. So it's therefore unlikely that a J2SE application would run unmodified on this platform unless it restricted itself to the API classes that appear on both platforms (which would severely limit its capabilities). Since the CLDC's requirements correspond to the capabilities of most handheld devices in use today, it's doubtful that any J2SE app will run unmodified on a given mobile device. You'll likely have to modify any app you want to port to J2ME. But don't sweat it. Consider it job security instead.