Java™ applications that run on MIDP devices are called MIDlets. MIDlets are portable across compatible mobile devices that support the same additional APIs that the MIDlet itself uses.
In order to be classified as a MIDlet, a mobile Java application must:
have all the files packaged and distributed in a Java Archive (JAR) file.
include a MANIFEST.MF file contained within the JAR file.
include a Java Application Descriptor (JAD) file.
have all .class files preverified before deployment. In current Java ME tools, the preverification is done automatically during the build process.
MIDlets are designed to support a particular MIDP version and are guaranteed to work properly with mobile devices that support that version. MIDlets may also utilize features from optional APIs, which may not be supported by the mobile device. In these cases, the optional API functionality is not supported.
When a MIDlet meets the requirements of the list above and is compliant with the MIDP version and optional APIs that the mobile device uses, it can be installed and executed on that mobile device correctly. The installation, uninstallation and runtime actions are handled by the Application Management Software (AMS) at that point.
A MIDlet suite is a collection of one or more MIDlets in a single JAR file. All the MIDlets in a suite are installed onto a device as a single entity. At runtime, if the device supports concurrent running of more than one MIDlet, all active MIDlets from a MIDlet suite run in the same Java VM.
A MIDlet cannot be launched from another MIDlet and a MIDlet suite cannot launch another MIDlet suite. In addition, no resources can be shared between MIDlets in different suites. Persistent data using Record Management System (RMS) is accessible to different MIDlet suites.
MIDlets are defined as part of a MIDlet suite in the JAD and JAR manifest attributes by using the MIDlet-<n> attribute. The application descriptor is also used for holding configurable application properties of a MIDlet suite.
MIDlet design differs to some extent from Java applications created with Java SE and Java EE platforms. The following list describes some of these differences:
Accessing native application data
CLDC does not support application defined class loading. Also note that Java ME has no mechanism to unload classes. All classes loaded during the running of a MIDlet will occupy the heap for the lifetime of the MIDlet. This applies to both MIDlet classes and the platform's API classes.
The Virtual Machine of Series 40 devices has a subset of the features of the higher end Java Virtual Machine (JVM). It is designed for embedded devices and has a smaller memory footprint.
Floating point numbers
The CLDC 1.1 configuration supports floating-point numbers. Note, however, that there are also some older devices based on the CLDC 1.0 configuration, which do not support floating-point numbers. In this case, applications cannot use floating point types such as floats or doubles. Floating-point-type calculations can still be made, but the results have to be stored in a string or as an integer array.
MIDP applications have to be preverified before runtime. CLDC does not support a full Java SE type bytecode verifier, but instead a different kind of bytecode verifier that takes less memory in the device, but requires application class files to be preverified during application development, more specifically in the compile process.
CLDC does not support finalisation (the finalize() method).
Java Native Interface (JNI)
Earlier versions of Series 40 devices do not support JNI and in them it is not possible to extend Java APIs beyond those that come with the device.
Java ME does not support reflection. In addition, Java ME does not support object serialization or Remote Method Invocation (RMI).
For more information on errors, see the Java tutorial Handling Errors Using Exceptions.
MIDP 2.0/2.1 does not support large user interface APIs such as Swing and AWT. Instead, MIDP implements High level UI components, which takes into account the capabilities of mobile devices.
CLDC does not support file access, but using FileConnection API (JSR-75) allows you to access the file system.
No thread groups or daemon threads
Although multithreading is possible with MIDP, it does not support thread groups or daemon threads. However, thread groups can be created at the application level by using a collection to store the thread objects.
Last updated 9 October 2013
We appreciate your feedback.