This document and all associated documents are subject to the terms of the Specification License
These documents define the Mobile Information Device Profile (MIDP) v2.0 Specification for the Java 2 Platform, Micro Edition (J2METM).
A profile of J2ME defines device-type-specific sets of APIs for a particular vertical market or industry. Profiles are more exactly defined in the related publication, Configurations and Profiles Architecture Specification, Sun Microsystems, Inc.
|
Date |
Version |
Description |
|---|---|---|
|
1-September-2000 |
MIDP 1.0 Specification |
Final MIDP 1.0 specification |
|
23-October-2001 |
MIDP 2.0, EG Draft 2 |
First complete draft published to the Expert Group |
|
6-November-2001 |
MIDP 2.0, EG Draft 3 |
Incorporated changes made during 30-31 October Expert Group meeting |
|
20-November-2001 |
MIDP 2.0, EG Draft 4 |
Incorporated changes discussed on EG mailing lists. |
|
18-December-2001 |
MIDP 2.0, EG Draft 5 |
Incorporated changes made during 5-6 December Expert group meeting and EG mailing lists. Published for Community Review |
|
12-February-2002 |
MIDP 2.0, EG Draft 6 |
Incorporated changes made during Community Review and internal EG mailing lists. |
|
12-March-2002 |
MIDP 2.0, EG Draft 7 |
Incorporated changes made during 20-21 February Expert group meeting and EG mailing lists. Published for Public Review |
|
09-April-2002 |
MIDP 2.0, EG Draft 8 |
Incorporated changes made during 26 March Expert group meeting and EG mailing lists. |
|
23-April-2002 |
MIDP 2.0, EG Draft 9 |
Incorporated changes discussed in the EG mailing lists. |
|
9-May-2002 |
MIDP 2.0, EG Draft 10 |
Incorporated changes discussed in the EG mailing lists. |
|
29-May-2002 |
MIDP 2.0, EG Draft 11 |
Incorporated changes discussed in the EG mailing lists. |
|
11-June-2002 |
MIDP 2.0, EG Draft 12 |
Incorporated changes discussed in the EG mailing lists. This draft is considered final in terms of functionality in all areas. Further clarifications and editorial changes may be made in one more revision, but only if necessary. |
|
15-July-2002 |
MIDP 2.0, EG Draft 13 |
Incorporated editorial changes and clarifications discussed in the EG mailing lists. This is final draft candidate 1. |
|
02-August-2002 |
MIDP 2.0, EG Draft 14 |
Incorporated editorial changes and clarifications from the RI and TCK teams and EG. This draft is being submitted to the PMO as Proposed Final Draft. |
|
04-September-2002 |
MIDP 2.0, EG Draft 15 |
Incorporated minor editorial changes and clarifications from the RI and TCK teams and EG. |
|
05-November-2002 |
MIDP 2.0, Final Specification |
Incorporated minor changes to the Security Policy Appendix, fixed an incorrect IETF URL, corrected MIDlet.platformRequest() method signature, finalized copyright co-ownership, and incorporated final license. |
This document is targeted at the following audiences:
This specification is contained in this HTML file and the following related documents:
There are requirements listed both in this document and the API documentation. Where there are conflicts, the requirements listed in this document override the API documentation.
Your comments on this specification are welcome and appreciated. Please send your comments to:
This document uses definitions based upon those specified in RFC 2119.
|
Term |
Definition |
|---|---|
|
MUST |
The associated definition is an absolute requirement of this specification. |
|
MUST NOT |
The definition is an absolute prohibition of this specification. |
|
SHOULD |
Indicates a recommended practice. There may exist valid reasons in particular circumstances to ignore this recommendation, but the full implications must be understood and carefully weighed before choosing a different course. |
|
SHOULD NOT |
Indicates a non-recommended practice. There may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label. |
|
MAY |
Indicates that an item is truly optional. |
This specification was produced by the JSR-118 Expert Group, as a part of the Java Community Process. The following companies and individuals, listed in alphabetical order, were members of the Expert Group:
This document, produced as a result of Java Specification Request (JSR) 118, defines the Mobile Information Device Profile (MIDP) v2.0 for the Java 2 Platform, Micro Edition (J2METM). The goal of this specification is to define an enhanced architecture and the associated APIs required to enable an open, third-party, application development environment for mobile information devices, or MIDs.
The MIDP 2.0 specification is based on the MIDP 1.0 specification and provides backward compatibility with MIDP 1.0 so that MIDlets written for MIDP 1.0 can execute in MIDP 2.0 environments.
The MIDP is designed to operate on top of the Connected, Limited Device Configuration (CLDC) which is described in Connected, Limited Device Configuration (JSR-30), Sun Microsystems, Inc. While the MIDP 2.0 specification was designed assuming only CLDC 1.0 features, it will also work on top of CLDC 1.1 (JSR-139), and presumably any newer versions. It is anticipated that most MIDP 2.0 implementations will be based on CLDC 1.1.
Mobile Information Devices (MIDs) span a potentially wide set of capabilities. Rather than try to address all such capabilities, the MIDP 1.0 (JSR-037) and MIDP 2.0 (JSR-118) expert groups agreed to limit the set of APIs specified, addressing only those functional areas that were considered absolute requirements to achieve broad portability and successful deployments. These include:
The above features are discussed in more depth in the associated Javadoc.
By the same reasoning, some areas of functionality were considered to be outside the scope of the MIDP. These areas include:
This section addresses issues that both implementers and developers will encounter when implementing and developing MIDP. While not comprehensive, this chapter does reflect the most important issues raised during deliberations of the MIDP Expert Group (MIDPEG).
As stated before, the goal of the MIDP is to create an open, third-party application development environment for MIDs. In a perfect world, this specification would only have to address functionality defined by the MIDP specification. In reality, most devices that implement the MIDP specification will be, at least initially, devices that exist on the market today. The High-Level Architecture shows a high-level view of how the MIDP fits into a device. Note that not all devices that implement the MIDP specification will have all the elements shown in this figure, nor will every device necessarily layer its software as depicted in this figure.
In the High-Level Architecture, the lowest-level block (MID) represents the Mobile Information Device hardware. On top of this hardware is the native system software. This layer includes the operating system and libraries used by the device.
Starting at the next level, from left to right, is the next layer of software, the CLDC. This block represents the Virtual Machine and associated libraries defined by the CLDC specification. This block provides the underlying Java functionality upon which higher-level Java APIs may be built.
Two categories of APIs are shown on top of the CLDC:
Note that in the figure, the CLDC is shown as the basis of the MIDP and device-specific APIs. This does not imply that these APIs cannot have native functionality (i.e., methods declared as native). Rather, the intent of the figure is to show that any native methods on a MID are actually part of the virtual machine, which maps the Java-level APIs to the underlying native implementation.
The top-most blocks in the figure above represent the application types possible on a MID. A short description of each application type is shown in the table below.
|
Application Type |
Description |
|---|---|
|
MIDP |
A MIDP application, or MIDlet, is one that uses only the APIs defined by the MIDP and CLDC specifications. This type of application is the focus of the MIDP specification and is expected to be the most common type of application on a MID. |
|
OEM-Specific |
An OEM-specific application depends on classes that are not part of the MIDP specification (i.e., the OEM-specific classes). These applications are not portable across MIDs. |
|
Native |
A native application is one that is not written in Java and is built on top of the MID's existing, native system software. |
It is beyond the scope of this specification to address OEM-specific or native applications.
The requirements listed in this chapter are additional requirements above those found in Connected, Limited Device Configuration (JSR-30 and JSR-139), Sun Microsystems, Inc.
At a high level, the MIDP specification assumes that the MID is limited in its processing power, memory, connectivity, and display size.
As mentioned before, the main goal of the MIDP is to establish an open, third-party application development environment for MIDs. To achieve this goal, the MIDPEG has defined a MID to be a device that SHOULD have the following minimum characteristics:
Examples of MIDs include, but are not restricted to, cellular phones, two-way pagers, and wireless-enabled personal digital assistants (PDAs).
For devices with the aforementioned hardware characteristics, there is still a broad range of possible system software capabilities. Unlike the consumer desktop computer model where there are large, dominant system software architectures, the MID space is characterized by a wide variety of system software. For example, some MIDs may have a full-featured operating system that supports multi-processing and hierarchical filesystems, while other MIDs may have small, thread-based operating systems with no notion of a filesystem. Faced with such variety, the MIDP makes minimal assumptions about the MID's system software. These requirements are as follows:
This section lists some explicit requirements of this specification. Other requirements can be found in the associated Javadoc. If any requirements listed here differ from requirements listed elsewhere in the specification, the requirements here take precedence and replace the conflicting requirements.
Compliant MIDP 2.0 implementations: