The Information Module Profile

Print-friendly Version

The primary J2ME profile based on the Connected Limited Device Configuration (CLDC) is the Mobile Information Device Profile (MIDP). Many MIDP-enabled devices - primarily mobile phones - are available on the market today, and a second version of the profile has already been defined through the Java Community Process (JCP). Any device that supports MIDP 2.0 and one or more optional packages like the Wireless Messaging API (WMA) or the Mobile Media API (MMA) provides a feature-filled environment for application development.

To support the user-interface (UI) behavior specified in MIDP, a device must have a display at least 96 pixels wide by 54 pixels high, and a keypad, a keyboard, or a touch screen. There are devices, though, with non-conventional user interfaces - and even some with no user interface - that otherwise meet the MIDP's minimum requirements, such as vending machines and tracking devices. These devices could still benefit from the non-UI features that MIDP adds to the basic application environment provided by the CLDC. It is to meet the needs of such devices that the Information Module Profile (IMP) is being developed through the JCP, as JSR 195.

The Information Module Profile (IMP) is a strict subset of the MIDP 1.0 specification. The primary difference is that IMP removes MIDP's display and input mechanisms - in other words, the javax.microedition.lcdui package is gone. Instead, IMP devices must provide their own implementation-specific classes to handle any interaction with the user they need. For example, a device with a set of external lights may provide an API to turn individual lights on or off. User-interface classes are not required - if there's no interaction with the user, there's no need for any UI support. (Note, however, that if a device is capable of supporting the MIDP UI classes, the application must use MIDP rather than IMP.)

IMP supports all the other features of MIDP 1.0, including the Record Management System (RMS), HTTP connectivity, and timers. The MIDlet application model is also supported, although the IMP specification refers to compliant applications as IMlets (pronounced to rhyme with "gimlets"), for consistency with the profile name. An IMlet is really just a MIDlet, though: An IMlet's main class extends javax.microedition.midlet.MIDlet. One or more IMlets are packaged together in an IMlet suite. The IMlet application descriptor and the manifest use property names starting with MIDlet-. An IMlet can be run unchanged on a MIDP device, providing the device supports the device-specific classes or optional packages the IMlet requires.

The only other difference between IMP and MIDP is that the microedition.profiles property (obtainable from the System.getProperty() method) must contain the string "IMP-1.0" instead of "MIDP-1.0", as in MIDP 1.0.

The IMP specification is still making its way through the Java Community Process, but you can write and test IMlets today. You can use the same tools you use for MIDlet development, as long as they make available to you the vendor-specific APIs you need. With no UI support available, you may find it simpler to use the MIDP reference implementation for your development than a more visual environment like the J2ME Wireless Toolkit.

Related Links

• JavaOne Online Session TS-1110 - The New Information Module Profile: How "Java Everywhere" Comes True!
  The authors of this contribution are the spec leads of the JSR mentioned above and want to share their knowledge of Information Modules, bringing "Java Everywhere," with their audience.