The high-level architecture of a typical Java ME device is illustrated below. At the heart of a CLDC implementation ("Configuration") is the Java Virtual Machine (JVM), which, apart from specific differences defined later in this specification, is compliant with the Java™ Virtual Machine Specification and Java™ Language Specification. The virtual machine typically runs on top of a Host Operating System that is outside the scope of CLDC.

On top of the virtual machine are the CLDC Library APIs; either the Full or Compact Libraries can be selected. The Generic Connection Framework provides lightweight network connections. In addition, Java ME profiles define additional libraries and optional packages that sit on top of the configuration layer.

 

High-Level Architecture

The Concept of a Java Application

The Connected Limited Device Configuration is not targeted to any specific device category. Many of the target devices may have an advanced graphical user interface, some target devices may be operated from a textual, character-based user interface, while some other target devices may not have any visual user interface or display at all. To cater to such a broad variety of devices, the application model defined in the CLDC Specification is intentionally very simple.

In the CLDC Specification, the term Java application is used to refer to a collection of Java class files containing a single, at least one method main that identifies the launch point of the application. As specified in The Java® Virtual Machine Specification, Java SE 8 Edition, §5.2, the method main must be declared public, static and void, as shown below:

public static void main(String[] args) 

A Java Virtual Machine conforming to the CLDC Specification starts the execution of a Java application by calling the method main.

Java ME profiles such as MEEP or MIDP may define alternative application models that extend or override the basic application model defined by the CLDC Specification.

Application Management

Many small, resource-constrained devices have minimal file system support or any other standard mechanism for storing dynamically downloaded information on the device. Therefore, a CLDC implementation shall not require that Java applications downloaded from an external source are stored persistently on the device. Rather, the implementation might just load the application and discard it immediately after execution.

However, in many potential CLDC devices, it is beneficial to be able to execute the same Java applications multiple times without having to download the applications over and over again. This is particularly important if applications are being downloaded over a wireless network, and the user could incur high downloading expenses. If a device implementing CLDC is capable of storing applications persistently, we assume that the device implementing has capabilities for managing the applications that have been stored in the device. At the high level, application management refers to the ability to:

• download and install Java applications,
• inspect existing Java applications stored on the device,
• select and launch Java applications,
• delete existing Java applications (if applicable).

Depending on the resources available on the device, a CLDC system can allow multiple Java applications to execute concurrently, or can restrict the system to permit only the execution of one Java application at a time. It is up to the particular CLDC implementation to decide if the execution of multiple Java applications is supported by utilizing the multitasking capabilities (if they exist) of the underlying host operating system, or by instantiating multiple logical virtual machines to run the concurrent Java applications.

Due to significant variations and feature differences among potential CLDC devices, the details of application management are highly device-specific and implementation-dependent. The actual details regarding application management are outside the scope of the CLDC Specification.

Security

With corporations and individuals depending increasingly on critical information stored in computer systems and networks, security issues are becoming ever more important, and even more so in the context of mobile computing and wireless networks. Due to its inherent security architecture, the Java development platform is particularly well-suited to security-critical environments. The security model provided by the Java Platform, Standard Edition (Java SE) provides developers with a powerful and flexible security framework that is built into the Java platform. Developers can create fine-grained security policies and articulate independent permissions for individual applications, all while appearing transparent to the end user.

Unfortunately, the total amount of code devoted to security in the Java Platform, Standard Edition far exceeds the total memory budget available for CLDC. Therefore, some simplifications are necessary when defining the security model for CLDC. The security model of CLDC is defined at three different levels:

1. Low-level security. Low-level security, also known as virtual machine security, ensures that the applications running in the virtual machine follow the semantics of the Java programming language, and that an ill-formed or maliciously-encoded class file does not crash or in any other way harm the target device.
2. Application-level security. Application-level security means that a Java application running on a device can access only those libraries, system resources and other components that the device and the Java application environment allows it to access.
3. End-to-end security. End-to-end security refers to a model that guarantees that any transaction initiated on a device is protected along the entire path from the device to/from the entity providing the services for that transaction (e.g, a server located on the Internet). Encryption or other means may be necessary to achieve this. End-to-end security is outside the scope of the CLDC Specification, and is assumed to be defined by those Java ME profiles that provide facilities for end-to-end software development.

Below we take a more detailed look at each of these levels.

Low-Level (Virtual Machine) Security

A key requirement for a Java Virtual Machine in a mobile information device is low-level virtual machine security. An application running in the virtual machine must not be able to harm the device in which the virtual machine is running, or crash the device. In a standard Java Virtual Machine implementation, this constraint is guaranteed by the class file verifier, which ensures that the bytecodes and other items stored in class files cannot contain illegal instructions, cannot be executed in an illegal order, and cannot contain references to invalid memory locations or memory areas that are outside the Java object memory (the object heap). In general, the role of the class file verifier is to ensure that class files loaded into the virtual machine do not execute in any way that is not allowed by the The Java® Virtual Machine Specification, Java SE 8 Edition.

As will be explained in more detail in Class File Verification the CLDC Specification requires that a conforming Java Virtual Machine must be able to reject invalid class files. This is guaranteed by the class file verification technology defined in The Java® Virtual Machine Specification, Java SE 8 Edition or optionally as presented in Class File Verification.

Application-Level Security

Even though class file verification plays a critical role in ensuring the security of the Java platform, the security provided by the class file verifier is insufficient by itself. The class file verifier can only guarantee that the given program is a valid Java application and nothing more. There are still several other potential security threats that will go unnoticed by the verifier. For instance, access to external resources such as the file system, printers, infrared devices, native libraries or the network is beyond the scope of the class file verifier. By application-level security, we mean that a Java application can access only those libraries, system resources and other components that the device and the Java application environment allows it to access. Application-level security leverages the Java SE security model enforced by the SecurityManager and AccessController. The security policy mechanisms are defined by other specifications.

Sandbox Model

In CLDC, application-level security is accomplished through use of a closed "sandbox." Applications run in a closed environment in which they can access only those libraries that have been defined by the configuration, profiles, and other classes supported by the device. Java applications cannot escape from this sandbox or access any libraries or resources that are not part of the predefined functionality. The sandbox ensures that a malicious or possibly erroneous application cannot gain access to critical system resources.

More specifically, the CLDC sandbox model requires that:

• Class files must be properly verified and guaranteed to be valid Java applications as defined by Class File Verification.
• The downloading, installation, and management of Java applications on the device takes place in such a way that the application programmer cannot modify or bypass the standard class loading mechanisms of the virtual machine.
• A closed, predefined set of Java APIs is available to the application programmer, as defined by CLDC, profiles (such as MEEP or MIDP) and manufacturer-specific classes.
• The set of native functions accessible to the virtual machine is closed, meaning that the application programmer cannot download any new libraries containing native functionality or access any native functions that are not part of the Java libraries provided by CLDC, profiles or manufacturer-specific classes.

Java ME profiles define which additional APIs are available to the application programmer. Profiles also may provide additional security solutions. Note that CLDC provides security permission classes for interacting with the security policies used in profiles built on CLDC.

Protecting System Classes

A central requirement for CLDC is the ability to support dynamic downloading of Java applications to the virtual machine. A possible application-level security hole in the Java Virtual Machine would be exposed if the downloaded applications could override or extend the set of the system classes provided in packages java.*, javax.microedition.* or other profile-specific or manufacturer-specific packages. A CLDC implementation shall ensure that the application programmer cannot override, modify, or add any classes to these protected system packages.

For security reasons, it is also required that the application programmer is not allowed to manipulate the class file lookup order in any way. Class file lookup order is discussed in more detail in Class File Lookup Order.

Additional Restrictions on Dynamic Class Loading

Dynamic loading of Java applications is a key feature of CLDC. However, the CLDC Specification defines the class loading mechanism of a virtual machine conforming to CLDC to be implementation-dependent, with one important restriction: by default, a Java application can load application classes only from its own Java Archive (JAR) file. This restriction ensures that Java applications on a device cannot interfere with each other or steal data from each other. Additionally, this ensures that a third-party application cannot gain access to the private or protected components of the Java classes that the device manufacturer or a service provider may have provided as part of the system applications. JAR files and applications representation formats are discussed in more detail in Class File Format and Class Loading.

End-to-End Security

A device conforming to the CLDC Specification is typically a part of an end-to-end solution such as a wireless network or a payment terminal network. These networks commonly require a number of advanced security solutions (e.g., encryption) to ensure safe delivery of data and code between server machines and client devices. Given the broad diversity of network infrastructure in the world, the CLDC expert group decided not to mandate a single end-to-end security mechanism. Therefore, all the end-to-end security solutions are assumed to be implementation-dependent and outside the scope of CLDC Specification.