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 of embedded device key input.
|
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.media.control |
[OPTIONAL] Features for Audio Control 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 8.
|
This document defines an EG Working Draft of the Embedded Profile for the Java Platform, Micro Edition (Java METM, version 8.0.0, aka MEEP 8.
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 |
---|---|---|
24-April-2012 |
MEEP 8 Speclead Draft |
Basis of EG work |
24-May-2013 |
MEEP 8 EDR Draft |
Result of EG work so far |
27-August-2013 |
MEEP 8 PR Draft |
Result of EG work so far |
22-November-2013 |
MEEP 8 Speclead Draft |
Incorporates results of PR into PR version |
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 |
An application is the entity that is launched by the Application Management Software (AMS). Each application consists of a class that extends the javax.microedition.midlet.MIDlet class and other classes and resources as may be needed by the application. |
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 |
Defines the protocol between an application and its execution environment through :
|
Application Management Software (AMS) |
Device system software that provides an environment in which Application 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 Application suites. The AMS is also responsible for providing the runtime execution environment that is required by the Application suite. It should be distinguished between the basic AMS functionality being an integral part of the MEEP 8 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 8. |
Application Suite |
The fundamental device application packaging component, contains one or more applications to be executed. The elements of an application suite are: the execution environment, the Application Suite Packaging, the Application Descriptor, the Application lifecycle, and Service Providers. See the Packaging chapter for details. |
Application Suite Lifecycle |
Defines the protocol between an Application Suite and the Application Management Software, including :
|
Authentication Provider |
Authenticates Clients as well as Applications and assigns Applications to Clients based on a mechanism being configurable at the time of system level configuration. One possible implementation is the PKI x.509 certificate based authentication as known from MIDP 3.0. |
Auto Start Application |
Application that is automatically launched when the device is powered on, and restarted automatically upon exit of the application. |
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 8 have a display, and implementing graphical capabilities is not mandatory for MEEP 8. MEEP 8 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. |
Blacklisting |
The possibility to prevent access to sensitive functionality for a particular Application or all applications assigned to a particular Client by removing the privileged Permissions of this application(s). This includes the immediate termination of the affected application, or of all applications assigned to the affected Client, respectively. This can happen using CRL or OCSP, but also using implementation-defined mechanisms such as ""push" blacklisting. |
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 8 have a display, and implementing graphical capabilities is not mandatory for MEEP 8. MEEP 8 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. |
Client |
A security entity, authenticated by the Authentication Provider, with an associated Security Protection Domain. This domain can be specific for this Client or may be shared between more than one or all Clients. The principal purpose of the Client is to identify the Security Protection Domain to which all applications of that Client are bound. As a consequence, the assignment of a security protection domain to a Client cannot be changed. |
The concurrent execution of two or more applications; primarily this means that the running applications 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 Application 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 Application suite of a set of required, prerequisite components, including LIBlets, services, optional packages, standard APIs, and proprietary APIs, including allowed versions, necessary for successful installation. |
Discovery Application |
Software that enables the download of MEEP 8 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 application suite 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 application. These features include support for input events and other high level user interface components. As not all MEEP 8 devices own a display and/or user input devices, the existence of display capabilities is not mandatory in MEEP 8. |
Display State |
A Display object has one of the following three states : foreground, background, and visible. These states define the level of access the application has to the exclusive resources related to that Display hardware on the device. Applications running on MEEP 8 devices without a display do not have a Display object of course, and for these devices a Display state does not exist. |
Execution Environment |
|
IMlet |
See Application. The applications in the IMP profiles have been called IMlets. As MEEP 8 is backward compatible to IMP-NG, IMlets are applications in the sense of the definition to be found there. |
IMlet Lifecycle |
See Application Lifecycle. The applications in the IMP profiles have been called IMlets. As MEEP 8 is backward compatible to IMP-NG, IMlets are applications in the sense of the definition to be found there. |
IMlet Suite |
See Application Suite. The applications in the IMP profiles have been called IMlets. As MEEP 8 is backward compatible to IMP-NG, IMlets are applications in the sense of the definition to be found there. |
IMlet Suite Lifecycle |
See Application Suite Lifecycle. The applications in the IMP profiles have been called IMlets. As MEEP 8 is backward compatible to IMP-NG, IMlets are applications in the sense of the definition to be found there. |
JME Embedded Profile Execution Environment |
Within this specification often also referred to as just "Execution Environment". Each application is executed in a separate environment that includes the 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 Application
suite or a LIBlet. The description includes the name of the Application
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 Application suite or a LIBlet, containing compiled Java classes and associated resources and metadata that constitute MEEP 8 applications or LIBlets. |
LIBlet |
A shareable software component that one or more Application 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. |
Media Support |
Defined in javax.microedition.media, and javax.microedition.media.control packages, allows applications the handling of audio media. |
Collectively, the techniques and components used to prepare Application 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 Application Suite |
An Application Suite that cannot be deleted. |
The process of (optional) discovering, deploying, and maintaining content on an embedded device. Support of Provisioning is optional in MEEP 8. |
|
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 application 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. A root certificate is trusted without validation as it is installed in the device's certificate store. It may be self signed, but does not have to. |
Security Policy |
Defines the mapping for a set of permissions that are available to applications assigned to a certain Client for a device. The Security Policy is assigned to this Client's protection Domain. |
Security Policy Provider |
Determines the per-application Permission set of an Application by determining the protection domain an application is bound to (identified by the Client the Application is assigned to) and then intersecting the permissions requested by the application. One possible implementation is policy file based mechanism as known from MIDP 3.0. |
Security Protection Domain |
Associates an application with a defined set of permissions that allow access to the functionality protected by the domain, based on the permissions granted. The mapping between Security Protection Domains and Clients is determined by the Security Service Provider. Every Client may have its own Security Protection Domain. It can be also decided that there is only one Security Protection Domain that fits all Clients. The assignment of the Client to a security protection domain cannot be changed. |
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 suite. |
Versioning |
A scheme to uniquely identify an Application 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 8.0 (MEEP 8) 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 8) claims to be binary backward compatible with
IMP-NG
, any IMlets written for IMP-NG
can execute in MEEP 8 environments without changes, assuming that the
used packages that have been mandatory in IMP / IMP-NG, but being optional
in MEEP 8 have been chosen in this implementation.
The JME Embedded Profile version 8.0.0 (MEEP 8) is designed to operate on top of the Connected Limited Device Configuration (CLDC), version 8, aka CLDC 8. This means the full CLDC 8 specification, but NOT its compact version with limited functionality, CLDC 8 compact. MEEP 8 is not designed to operate on top of the compact version of CLDC 8!
MEEP-8.0.0 profile is identified by the string "MEEP-8.0"
.
This string MUST be used to identify the JME Embedded Profile as the
recent one in the following contexts:
"MEEP-8.0"
MUST appear in the value of the
microedition.profiles
system property
as described in
the system property chapter.
"MEEP-8.0"
MUST be the value of the application
descriptor attribute for MEEP 8 applications as defined in
Application Descriptor Attributes,
Application Descriptor, and
Operational Attributes and Applications.
"MEEP-8.0"
MUST be the value of the manifest
attribute for MEEP 8 applications as defined in
JAR Manifest.
MEEP 8 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 8 offers the following new features :
Embedded devices 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 8 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 profile 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 8. These areas include :
This section addresses issues that both implementers and developers will encounter when working with the MEEP 8. While not comprehensive, this section does reflect the most important issues raised during deliberations of the MEEP 8 Expert Group as well as experiences with previous versions.
As previously stated, the goal of the MEEP 8 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 8 specification itself. In reality, most devices that implement the MEEP 8 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 8 fits into an information module's software architecture. Note that not all devices that implement the MEEP 8 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 8 High Level Architecture |
---|
In the MEEP 8 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 8 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 applications. Native Applications are non-Java applications that make use of the device system software, but may also interact and share data with MEEP 8 implementations.
The requirements listed in this section are additional requirements above those found in into CLDC 8, the required underlying configuration for MEEP 8.
At a high level, the MEEP 8 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 8 is to establish an open, third-party application development environment for information modules. To achieve this goal, the MEEP 8 Expert group has defined the target device that SHOULD have the following minimum characteristics :
Implementers should be aware that his is by far not enough for the implementation of all (or a higher number of) optional packages described in this specification.
The Profile Sets chapter describes a number of proposed and possible (but by far not all) possible combinations of optional packages being expected to become the most popular ones, called Profile sets. It includes also minimal and recommended memory amounts for those combinations.
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 file systems, while other devices may have small, thread-based operating systems with no notion of a file system. 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 specifications. 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 8 implementations:
Copyright (c) 2014, Oracle and/or its affiliates. All Rights Reserved. Use of this specification is subject to license terms.
i