See: Description
Package | Description |
---|---|
javax.microedition.cellular |
[OPTIONAL] Provides classes to obtain information about cellular networks the device is
registered on.
|
javax.microedition.event |
[OPTIONAL] Events for system state changes and application to application
communication.
|
javax.microedition.io |
[OPTIONAL] Networking support based on the Generic Connection Framework
Specification.
|
javax.microedition.key |
[OPTIONAL] Support for keys of the embedded device.
|
javax.microedition.lui |
[OPTIONAL] Set of features to implement Line-oriented User Interface.
|
javax.microedition.media |
[OPTIONAL] Features for Audio support on embedded Devices.
|
javax.microedition.midlet |
The Application and the environment in which the application runs.
|
javax.microedition.power |
[OPTIONAL] Power management.
|
javax.microedition.rms |
[OPTIONAL] Mechanism for applications to persistently store data and later
retrieve it.
|
javax.microedition.swm |
[OPTIONAL] Provides extended software management features to MEEP.
|
This document defines the EDR Draft of the Embedded Profile for the Java Platform, Micro Edition (Java METM, version 1.0, aka MEEP-1.0.
This document and all associated documents are subject to the terms of the JCP and associated agreements (JSPA).
A profile of Java ME defines device-type-specific sets of APIs for a particular vertical market or industry.
Date |
Version |
Description |
---|---|---|
31-July-2003 |
IMP 1.0, Final Specification |
Final IMP 1.0 specification |
30-November-2005 |
IMP-NG, Final Specification |
Final IMP-NG specification |
24-April-2012 |
MEEP Speclead Draft |
Basis of EG work |
24-May-2013 |
MEEP EDR Draft |
Result of EG work so far |
The preferred forum for comments will be JSR 361 project on java.net.
Alternatively, comments may be sent to jsr-361-comments@jcp.org.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
Code examples are formatted as follows :
DataInputStream inputStream2 = new DataInputStream(bais2); try { quote2 = inputStream2.readInt(); } catch (EOFException eofe) { // ... } |
Table 1-1 : Glossary |
|
---|---|
Application Attributes |
Name-value pairs that represent application properties and configuration, are logically bound to an application suite, and are contained within an the suite's Manifest and/or JAD. |
Application Lifecycle |
See IMlet Lifecycle. |
Application Management Software (AMS) |
Device system software that provides an environment in which IMlet suites are installed, started, stopped, and deleted. The AMS is responsible for handling any errors that may occur during the installation, execution, and removal of IMlet suites. The AMS is also responsible for providing the runtime execution environment that is required by the IMlet suite. It should be distinguished between the basic AMS functionality being an integral part of the MEEP-1.0 runtime environment on the one hand, and the extended SWM functionality as defined in the javax.microedition.swm package on the other hand. The extended SWM functionality defined in this package is optional for MEEP-1.0. |
Application Suite |
See IMlet Suite. |
Application Suite Lifecycle |
|
Auto Start IMlet |
IMlet that is automatically launched when the device is powered on, and restarted automatically upon exit of the IMlet. |
Auxiliary Display |
Display hardware that is not an integral part of the device, and is not permanently connected to it. Not all devices implementing MEEP-1.0 have a display, and implementing graphical capabilities is not mandatory for MEEP-1.0. MEEP-1.0 devices MAY have one or several displays though. Auxiliary displays are transient, may not always be available for use by the device, and may be attached to the device by a wired or wireless connection. |
Built-In Display |
Display hardware that is an integral part of and permanently connected to the device, such as the main or external display of a mobile phone. Not all devices implementing MEEP-1.0 have a display, and implementing graphical capabilities is not mandatory for MEEP-1.0. MEEP-1.0 devices MAY have one or several displays though. |
Certificate (Public Key Certificate) |
Also known as an identity certificate, an electronic document that incorporates a digital signature to bind together a public key with an identity - information such as the name of a person or an organization, their address, and so forth. The certificate can be used to verify that a public key belongs to an individual. |
Certificate Authority |
An entity that issues digital certificates on behalf of the certificate owner, as a trusted third party, as part of Application Suites Trust Model Using X.509 PKI. |
The concurrent execution of two or more IMlets; primarily this means that the running IMlets SHOULD behave as though they were running independently, in terms of runtime execution environment, data isolation, error handling, and scheduling. |
|
Dependency Declaration Chain |
The list of required, prerequisite components that an IMlet suite has expressed as required to be present for successful installation. This list must form a tree (an acyclic directed graph) in which each vertex in the graph represents a unique dependency. |
Dependency Expression |
The specification by an IMlet suite of a set of required, prerequisite components, including LIBlets, services, standard APIs, and proprietary APIs, including allowed versions, necessary for successful installation. |
Discovery Application |
Software that enables the download of MEEP-1.0 applications, usually initiated by external or internal triggers. Installation mechanisms like Bluetooth™ wireless technology, serial cable, IrDA™, SMS etc. will be called "external triggers" to initiate provisioning here. Also “internal triggers” such as Timer events or requests from running Java applications are solutions one can think of. Which trigger is used by an implementation is outside the scope of this specification. The goal of such a generic solution is to ensure that an IMlet can be downloaded by implementations of several manufacturers – not depending on what kind of trigger is used. For every kind of external trigger, security is an issue to keep in mind. Depending on security requirements it is strongly recommended to use security mechanisms such as passwords to avoid unauthorized triggering by external sources. |
Display Capabilities |
The set of user interface features that a Display supports and may be used by an IMlet. These features include support for input events and other high level user interface components. As not all MEEP-1.0 devices own a display and/or user input devices, the existence of display capabilities is not mandatory in MEEP-1.0. |
Display State |
A Display object has one of the following three states : foreground, background, and visible. These states define the level of access the IMlet has to the exclusive resources related to that Display hardware on the device. IMlets running on MEEP-1.0 devices without a display do not have a Display object of course, and for these devices a Display state does not exist. |
Display Hardware State |
Represents the state of the display hardware resource known to the device. The display state can be used by an application to determine if the display hardware is available for use. If there is no display hardware known to the display, there is no display hardware state of course. |
Execution Environment |
|
IMlet Lifecycle |
Within this specification often also referred to as "Application Lifecycle". Defines the protocol between an IMlet and its execution environment through :
|
IMlet Suite |
Within this specification often also referred to as "Application Suite". The fundamental application packaging component, consisting of a single JAR containing one or more applications. |
IMlet Suite Lifecycle |
Within this specification often also referred to as "Application Suite Lifecycle". Defines the protocol between an IMlet / Application Suite and the Application Management Software, including :
|
JME Embedded Profile Execution Environment |
Within this specification often also referred to as just "Execution Environment". Each IMlet is executed in a separate environment that includes the IMlet / Application suite's classes, its shared libraries and the requested configuration, profile and optional APIs. |
JAD (Java Application Descriptor) |
A collection of attribute/value pairs used to describe an IMlet
suite or a LIBlet. The description includes the name of the IMlet
suite or a LIBlet, the location and size of the JAR, and
configuration, profile, and dependency requirements. JADs may contain
attributes defined by the profile (prefixed by |
JAR (Java Archive) |
An archive used to distribute an IMlet suite or a LIBlet, containing compiled Java classes and associated resources and metadata that constitute MEEP-1.0 applications or LIBlets. |
LIBlet |
A shareable software component that one or more IMlet suites may use at runtime. |
Licensee Open Classes |
Also known as OEM Specific Classes, proprietary packages that do not logically fall into the category of a Java ME configuration, profile, or optional package. |
Manifest |
Contains information that describes the contents of a JAR. Located at /META-INF/MANIFEST.MF within a JAR; same syntax as the JAD and may share the same attributes. |
Collectively, the techniques and components used to prepare IMlet suites for distribution, including Java archive (JAR), Manifest, Java Application Descriptor (JAD), and resources. |
|
Permission |
Represents a specific access to a particular resource, such as an API or function, and the authorized use of that resource. |
Persistent IMlet Suite |
An IMlet / Application Suite that cannot be deleted. |
The process of discovering, deploying, and maintaining content between a server and a client device. Support of Provisioning is optional in MEEP-1.0. |
|
RMS |
Defined in javax.microedition.rms, Record Management System allows applications to persistently store and later retrieve data. |
RMS Record Tag |
An integer tag associated with a record in an RMS record store, specified at runtime by an IMlet to either assign the tag to a record or to be used as a filter while searching a record store. |
Root Certificate |
A certificate or equivalent entity occupying the top-most position in a certificate chain and forming the root trust level that is inherited by all certificates below it in the certificate chain. |
Security Policy |
Defines the mapping for a set of permissions that are available to applications running within each of the individual security protection domains for a device. |
Security Protection Domain |
Associates an IMlet / Application suite with a defined set of permissions and related interaction modes that allow access to the functionality protected by the domain, based on the permissions granted. |
Service |
A service is a well-known set of Java interfaces and (usually
abstract) classes as defined by |
Service Provider |
A service provider is a specific implementation of a service. Service providers are packaged and distributed in LIBlets or in the application. |
Versioning |
A scheme to uniquely identify an IMlet suite, LIBlet, or API by major, minor, and micro version, to enable identification for provisioning (if supported) and dependency expression. |
X.509 Public Key Infrastructure |
A cryptography standard for that specifies standard formats for public key certificates and a certificate chain validation algorithm. |
This specification was produced by the JSR XXX Expert Group, as a part of the Java Community Process. The following companies and individuals, listed in alphabetical order, are members of the Expert Group :
This document, produced as a result of Java Specification Request (JSR) 361, defines the Embedded Profile for the Java Platform, Micro Edition (Java METM). 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 information modules.
The JME Embedded Profile version 1.0 (MEEP-1.0) specification is based on the
IMP 1.0 and
IMP-NG specifications, and
many features are inspired by or have been adopted from
MIDP 3.0.
JME Embedded Profile (MEEP) claims to be binary backward compatible with
IMP-NG
, any IMlets written for IMP-NG
can execute in MEEP environments without changes, assuming that the
used packages that have been mandatory in IMP / IMP-NG, but being optional
in MEEP-1.0 have been chosen in this implementation.
The JME Embedded Profile version 1.0 (MEEP-1.0) is designed to operate on top of the Connected Limited Device Configuration (CLDC), version 8. TODO: Add a link here to CLDC-8 spec once it exists.
MEEP-1.0 profile is identified by the string "MEEP-1.0"
.
This string MUST be used to identify the JME Embedded Profile as the
recent one in the following contexts:
"MEEP-1.0"
MUST appear in the value of the
microedition.profiles
system property
as descibed in
the system property chapter, while identification strings of
older IMP versions like "IMP-NG"
MUST NOT appear there.
"MEEP-1.0"
MUST be the value of the application
descriptor attribute for MEEP-1.0 applications as defined in
Application Descriptor Attributes,
Application Descriptor, and
Operational Attributes and Applications.
"MEEP-1.0"
MUST be the value of the manifest
attribute for MEEP-1.0 applications as defined in
JAR Manifest.
MEEP-1.0 introduces a number of new features that build upon the previous success of IMP and IMP-NG. There are several reasons leading to the need of a new profile version of information modules :
As a consequence, MEEP-1.0 offers the following new features :
Information Modules (IMs) span a potentially wide set of capabilities. It is not the purpose of this specification to address all such capabilities, but rather to limit the set of APIs specified, addressing only those functional areas that were considered absolute requirements needed to achieve broad portability and successful deployments. The MEEP-1.0 Expert Group has agreed to continue and extend this philosophy to expand upon the existing IMP functionality in all areas, improve interoperability across implementations, and build upon the success of previous IMP versions by enhancing the profile in the following areas :
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 MEEP-1.0. These areas include :
This section addresses issues that both implementers and developers will encounter when working with the MEEP-1.0. While not comprehensive, this section does reflect the most important issues raised during deliberations of the MEEP-1.0 Expert Group as well as experiences with previous versions.
As previously stated, the goal of the MEEP-1.0 is to create an open third-party application development environment for information modules. Ideally, this specification would only have to address functionality defined by the MEEP-1.0 specification itself. In reality, most devices that implement the MEEP-1.0 specification will incorporate features and components that exist in today's information module market. The High Level Architecture diagram (Figure 1-1) provides an overview of how MEEP-1.0 fits into an information module's software architecture. Note that not all devices that implement the MEEP-1.0 specification will incorporate all of the elements depicted in Figure 1-1, nor will every device necessarily implement a software stack precisely as depicted in this figure.
Figure 1-1 - MEEP-1.0 High Level Architecture |
---|
![]() |
In the MEEP-1.0 High Level Architecture, the lowest level block - labeled Embedded Device (ED) - represents the device hardware. Logically above this hardware is the native device system software; this layer includes the operating system and runtime libraries used by the device.
Logically above the native system software is the Java Virtual Machine and configuration layer. This block represents the Java Virtual Machine and associated libraries defined by the CLDC-8 specification. This block provides the underlying Java functionality upon which higher level Java APIs may be built, such as the MEEP-1.0 and optional packages.
Licensee Open Classes, sometimes also called OEM Specific Classes, are not JSRs, and are generally proprietary packages that do not logically fall into the category of a Java ME configuration, profile, or optional package.
OEM Specific Applications may make use of non-standard packages and APIs, and may be IMlets. Native Applications are non-Java applications that make use of the device system software, but may also interact and share data with MEEP-1.0 implementations.
The requirements listed in this section are additional requirements above those found in CLDC-8. TODO: Add a link here to CLDC-8 spec once it exists.
At a high level, the MEEP-1.0 specification assumes that the device is limited in its processing power, memory, connectivity, and display size.
As previously stated, the main goal of the MEEP-1.0 is to establish an open, third-party application development environment for information modules. To achieve this goal, the MEEP-1.0 Expert group has defined the target device that SHOULD have the following minimum characteristics :
Examples of devices include (but are not restricted to) wireless modules, medical monitor devices, electrical or water meters, and cellular IP phones.
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 space of information modules is characterized by a wide variety of system software. For example, some devices may have a full-featured operating system that supports multi-processing and hierarchical filesystems, while other devices may have small, thread-based operating systems with no notion of a filesystem. Faced with such variety, this specification makes minimal assumptions about the system software. These requirements are as follows :
In case a persistent storage option has been chosen, the following additional requirement has to be considered :
In case a UI option has been chosen, the following additional requirements have to be considered :
This section lists some explicit requirements of this specification. Other requirements can be found in the associated API specifictions. If any requirements listed here differ from requirements listed elsewhere in the specification, the requirements here take precedence and replace the conflicting requirements.
Compliant MEEP-1.0 implementations:
CommConnection
interface.
Copyright (c) 2013, Oracle and/or its affiliates. All Rights Reserved. Use of this specification is subject to license terms.