HomeDigital EditionSys-Con RadioSearch Java Cd
Advanced Java AWT Book Reviews/Excerpts Client Server Corba Editorials Embedded Java Enterprise Java IDE's Industry Watch Integration Interviews Java Applet Java & Databases Java & Web Services Java Fundamentals Java Native Interface Java Servlets Java Beans J2ME Libraries .NET Object Orientation Observations/IMHO Product Reviews Scalability & Performance Security Server Side Source Code Straight Talking Swing Threads Using Java with others Wireless XML

Developers new to the Mobile Information Device Profile (MIDP) are often surprised by some of the limitations and their consequences, because they seem to be omissions of obviously needed functionality.

In this article I discuss my personal favorites - the rationale (to the degree I can discern it) for them; the impact of their omission; workarounds and alternatives; and the efforts that exist to address these limitations. These efforts often involve Java Specification Requests (JSRs), which I'll reference when applicable.

Some of the limitations are in fact limitations of the Connected Limited Device Configuration (CLDC). As I write this article the MIDP is the only finalized profile under the CLDC, so I'll discuss CLDC limitations in the context of the MIDP.

URLs for all referenced JSRs and software products are provided in the Resources section at the end of the article.

No Floating Point Support
The CLDC doesn't require floating-point support - neither the float and double primitives, nor the Float and Double classes, are present in the CLDC. The CLDC specification states this is because "...the majority of CLDC target devices don't have hardware floating-point support, and...the cost of supporting floating-point in software was considered too high." However, there are obviously many valuable applications that you simply can't implement without floating-point calculations.

Floating-point support is being considered for inclusion in the next version of the CLDC specification (JSR139), but for now if your application requires floating-point calculations you have the following options:

  • The targeted platforms' OEMs might provide APIs that support floating-point.
  • You can use publicly available software for floating-point emulation.
  • You can implement your own floating-point emulation software.

    The CLDC doesn't preclude OEMs from supplying their own floating-point APIs. If OEM floating-point APIs are available for your targeted platforms, you should use them because most likely they'll execute native code, giving better performance and accuracy than floating-point emulation software.

    Without access to OEM APIs you can either use publicly available floating-point emulation software such as MathFP (see Resources) or create your own. If you implement your own you must address issues such as the accumulation of truncation and rounding errors, and rigorously test your software.

    Regardless of whether you use OEM-supplied APIs or floating-point emulation, consider creating your own classes to wrap all calls to the solution available to you. This will make it easier to debug your applications and to port them to other platforms, because your changes will be centralized within the wrapper classes. If you model your wrappers as closely as possible after the J2SE Float, Double, and Math classes, you may also reduce your effort in transitioning to the next version of the CLDC. It's reasonable to assume that if it does support floating-point it will provide Float, Double, and Math classes that are subsets of their J2SE counterparts.

    No JNI, No Telephony APIs, No Sound APIs
    I group these together because the absence of telephony and sound APIs are good examples of the impact of the lack of support for the Java Native Interface, which the CLDC specification says is omitted because:

    1. JNI would allow applications to compromise the CLDC security model.
    2. A full JNI implementation would be "too expensive given the strict memory constraints of CLDC...devices."
    The lack of JNI eliminates the possibility of third-party or custom workarounds for providing missing functionality; the only way MIDP applications can access native functionality is if the OEMs provide APIs for it. For example, on an MIDP-enabled cell phone, a phonebook MIDlet could only initiate a phone call if the cell phone's manufacturer provides Java APIs to support it. Likewise, if a MIDlet game wishes to use snazzy sound effects that are available on the phone via native libraries, it can do so only if the phone's OEM provides Java APIs for sound.

    It doesn't appear that any JSR is considering the incorporation of JNI support into CLDC or MIDP. Optional J2ME telephony APIs are being defined under JSR120, and a base sound API is listed for investigation under JSR118 (the next generation of the MIDP specification, aka MIDP_NG).

    No RMI
    RMI is not supported due to the lack of support for reflection. The CLDC doesn't support reflection because the ability to dynamically examine an object could lead to the subversion of features of that object, thereby compromising security. Reflection is used in serialization to discover class attributes that need to be serialized, and an object must be serialized to be transported via RMI.

    Without RMI an MIDP client can't directly interface with existing or new servers that provide only RMI interfaces. kSOAP provides an MIDP-implementation of SOAP that can be used as an alternative to an RMI architecture (kSOAP includes an interface and classes for implementing a partial replacement for serialization). Some applications may also consider Softwired's iBus, which implements an MIDP JMS solution.

    The inclusion of reflection and serialization doesn't appear to be under consideration in any JSRs. A proposed final draft of a J2ME RMI profile has been developed under JSR66.

    The Only Required Protocol Is HTTP
    The CLDC provides a connection framework but doesn't mandate the support of any network protocols. The MIDP mandates the support of a subset of HTTP 1.1; OEMs can provide support for other protocols, but are not required to. The CLDC and MIDP both state that a larger set of protocols is not mandated because of memory limitations and environmental conditions (e.g., whether a cell phone uses a circuit- or packet-switched network) specific to the various devices.

    This means your MIDlets can't use datagrams (UDP), serial ports, HTTPS, sockets, or other protocols unless the OEMs of the platforms you deploy to support them. Support for these protocols would provide some of the following benefits:

    • Since UDP is more efficient than HTTP, datagrams would provide a transport mechanism that could use the limited bandwidth and speed of wireless connections more cheaply than HTTP (at the cost of UDP's lack of reliable delivery).
    • Serial port support could provide a simple, efficient connection for hot-synching MIDlet's data stores, such as address books, with their PC-based counterparts.
    • Support for HTTPS would promote the security of sensitive data transactions, which are necessary for mobile commerce.
    • Support for sockets would allow the development of client/server applications with significantly better speed than HTTP provides.
    Sun's Web page for JSR118 states that support for sockets, datagrams, and HTTPS are "functional areas to be investigated"; no mention is made of serial port connectivity. Until and unless the next version of the spec addresses the issue, we're dependent upon the good graces of the OEMs to support the desired protocols.

    As a partial alternative to HTTPS, you can encrypt your data using J2ME crypto APIs available from Bouncy Castle.

    No Shared Libraries
    MIDlets are deployed in a MIDlet suite, which is a JAD file plus a JAR file containing one or more MIDlets. MIDlets in the same suite can share classes within the suite, but the MIDP specification makes no provision for sharing classes among MIDlet suites unless those libraries are provided by the OEM and reside on the platform. This limitation stems from concerns including security and versioning issues.

    This limitation can cause the size of your deployed applications to be larger than they could be with custom shared libraries, which is a significant concern because of the limited storage capacities of Mobile Information Devices (MIDs). If you think the limitation can be avoided simply by packaging all your MIDlets into a single suite, consider the situation in which you wish to sell separate suites that use common functionality provided by floating-point emulation code. Not only will each suite incur the size cost of the floating-point class files, but each suite needs to be repackaged and redeployed whenever you wish to incorporate floating-point bug fixes.

    None of the JSR descriptions at Sun's Web site mention efforts to address this issue. It's unclear whether OEMs could provide their own solutions without breaking conformance to the MIDP specification.

    No Custom Display Widgets for the High-Level UI
    You can't create custom visual components (aka widgets) that can be used with the MIDP's high-level UI APIs. Class javax.microedition.lcdui.Form is the only screen that can contain disparate widgets, and it only allows components that extend class javax.microedition.lcdui.Item. However, Item's paint method has protected access, so a custom subclass of Item can't display itself to the screen (if you try to get around this limitation by placing your subclass in package javax.microedition.lcdui, there's still no guarantee that the widget will display properly).

    This constraint results from a focus of the MIDP specification upon interoperability, a write-once, run-anywhere goal. By preventing the inclusion of custom widgets, the high-level UI eliminates the possibility of a custom widget displaying satisfactorily on one MIDP device but not another. However, it also limits the ability of developers to provide visually distinctive displays, and to explore new ways of interacting with the user in the small real estate of a wireless device's screen.

    JSR118 is investigating UI issues that may include support for the creation of custom widgets. For the present, both the Motorola Lightweight Windowing Toolkit (LWT) and Nextel's Open Source Windowing Toolkit (OWT) provide UI frameworks that support the creation of custom widgets.

    No Control Over High-Level UI Layout
    The high-level UI API mentioned earlier also doesn't provide control over the layout of visual components. The layout is vertical, with focusable widgets always added to a new line. You also can't specify the horizontal (left, centered, right) placement of items. For example, you can't place three text fields horizontally adjacent, separated by hyphens, to create a social security field, nor can you center a text label above a widget.

    The rationale for this is the same as for preventing the creation of custom widgets - to promote interoperability. Similarly, this limitation may be addressed by JSR118, and both Motorola's LWT and Nextel's OWT provide alternative approaches.

    No Shared Data
    The MIDP's persistent data mechanism, the Record Management System, doesn't allow MIDlet suites to share data. Any MIDlet in a suite can access the persistent data stored by other MIDlets in the same suite, but not the persistent data stored by MIDlets in any other suite.

    This is a security precaution to prevent malicious applications from accessing sensitive data created by other applications. However, it also precludes the sharing of data that might be reasonably shared, and requires that the entry of that data be duplicated, which may be particularly annoying to the user given the limited keyboards of many MIDs. Consider the deployment on a cell phone with a numeric keypad only (letters are entered by multiple presses of a number) of multiple m-commerce MIDlet suites that require credit card information, which the user will have to enter for each suite.

    Many security issues are under consideration in JSR118, although it's unclear whether there will be any changes in the security policy for data sharing.

    Last Thoughts
    As with many nascent technologies, the MIDP has limitations that you may need to address to produce your applications. In some cases you may be able to find or develop custom software to provide the functionality you need. In other cases the functionality may only be available if the OEMs of your targeted platforms provide it. In either case the solutions may compromise the portability of your applications. You can reduce the impact on portability, or at least reduce the effort to port to different platforms, by providing wrappers for code that's dependent upon custom or OEM solutions, and by keeping abreast of, and conforming to, candidate standards under consideration as JSRs.


    1. Bouncy Castle: www.bouncycastle.org
    2. JSR 66 - J2ME RMI Profile: www.jcp.org/jsr/detail/66.jsp
    3. JSR 118 - MIDP Next Generation: www.jcp.org/jsr/detail/118.jsp
    4. JSR 120 - Wireless Telephony Communication APIs: www.jcp.org/jsr/detail/120.jsp
    5. JSR 139 - CLDC, Next Generation: www.jcp.org/jsr/detail/139.jsp
    6. kSOAP: http://ksoap.enhydra.org/index.html
    7. Motorola Lightweight Toolkit: http://developers.motorola.com/developers/wireless/tools
    8. Nextel Open Windowing Toolkit: http://nextel.sourceforge.net
    9. OTA User Initiated Provisioning Recommend Practice: http://java.sun.com/products/midp/OTAProvisioning-1.0.pdf
    10. Softwired/iBus: www.softwired-inc.com/products/mobile/mobile.html

    Author Bio
    Glen Cordrey is a developer of J2ME and J2EE solutions for DigitalFocus in Herndon, Virginia. He is the architect of Nextel's J2ME toolkits, the principal author of Nextel's J2ME Developer's Guide, and a member of the MIDP_NG Expert Group. [email protected]

    All Rights Reserved
    Copyright ©  2004 SYS-CON Media, Inc.
      E-mail: [email protected]

    Java and Java-based marks are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries. SYS-CON Publications, Inc. is independent of Sun Microsystems, Inc.