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.
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:
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:
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.
- JNI would allow applications to compromise the CLDC security model.
- A full JNI implementation would be "too expensive given the strict memory constraints of CLDC...devices."
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).
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:
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.
- 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.
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.
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.
- Bouncy Castle: www.bouncycastle.org
- JSR 66 - J2ME RMI Profile:
- JSR 118 - MIDP Next Generation:
- JSR 120 - Wireless Telephony Communication APIs:
- JSR 139 - CLDC, Next Generation:
- Motorola Lightweight Toolkit:
- Nextel Open Windowing Toolkit:
- OTA User Initiated Provisioning Recommend Practice:
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.