J2ME and iAppli
As I've mentioned, a J2ME application environment is the combination of a Sun-defined "configuration" and "profile." To refresh, Sun defines a configuration as follows:
Configurations are composed of the two low-level APIs and optimized virtual machines targeted at two broad categories of devices: (1) those with 128512K of memory available for the Java technology environment (and applications), and (2) those with 512K+ available for the Java technology environment (and applications).
A profile, meanwhile, is defined as this:
A profile is a specification that details the Java technology APIs, built on top of and utilizing the underlying Configuration, necessary to provide a complete runtime environment for a specific kind of device.
Mobile wireless devices all use the Common Limited Device Configuration (CLDC), and most implement the Mobile Information Device Profile (MIDP) on top of that. MIDP devices have been widely available in the United States from Motorola for well over a year. (Nextel was the first carrier to market with these devices in the United States). Asian carriers currently supporting J2ME devices include ChinaConnect (China), LG Telecom (South Korea), and DoCoMo (Japan).
It should be mentioned that DoCoMo was far enough ahead of the "power curve" that the company, in fact, developed its own profile (known as iAppli) to run on top of a J2ME CLDC virtual machine. iAppli is similar in concept to MIDP but is incompatible at a class level. DoCoMo wrote its own UI, I/O, networking, and utility packages (all defined in the com.nttdocomo package). Like J2ME MIDP, the iAppli packages are limited in functionality yet are still powerful enough to build networked utilities, games, and productivity applications. As I mentioned earlier, DoCoMo also brings a powerful billing model to the table that instantly hooks approved developers into the i-Mode/iAppli revenue stream.