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:
extend the MIDP-defined abstract class javax.microedition.midlet.MIDlet, which controls the MIDlet
lifecycle.
be 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.
For more information, see sections MIDlet life cycle and Deploying MIDlets to a device.
A MIDlet suite is a collection of one or more MIDlets in a single JAR file. All of 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 can not be launched from another MIDlet and a MIDlet suite can not 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 application
descriptor file (JAD) by using the MIDlet-<n> attribute.
The application descriptor is also used for holding configurable application
properties of a MIDlet suite. For detailed information on the use of the application
descriptor and mandatory or optional attributes, see section Packaging
MIDlets.
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
Accessing native Symbian OS or Series 40 Nokia OS application data is restricted in mobile Java. However, using the optional FileConnection and PIM APIs (JSR-75) allows you some access to native data.
Class loading
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.
Virtual machine
The Virtual Machine of Symbian and 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.
Preverification
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.
Finalization
CLDC does not support finalization
(the finalize() method).
Java Native Interface (JNI)
The Symbian platform Supports JNI from S60 3rd Edition Feature Pack 2 onwards. Earlier versions of Symbian devices and 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.
Reflection
Java ME does not support reflection. In addition, Java ME does not support object serialization or Remote Method Invocation (RMI).
Error handling
Java ME has different requirements for error handling. For more information on errors, see the Java tutorial Handling Errors Using Exceptions.
High-level APIs
MIDP 2.0/2.1 does not support large user interface APIs such as Swing and AWT. Instead, MIDP implements LCDUI, which takes into account the capabilities of mobile devices. From S60 3rd Edition Feature Pack 2 onwards, the Symbian platform also supports eSWT, a more feature rich UI toolkit that is comparable to the aforementioned Swing and AWT APIs.
File handling
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.