CLDC 8

Adherence to the Java Virtual Machine Specification

The general goal for a virtual machine conforming to CLDC 8 is to be as compliant with The Java® Virtual Machine Specification, Java SE 8 Edition as is possible within strict memory constraints of CLDC target devices. The differences between a Java Virtual Machine conforming to CLDC and The Java® Virtual Machine Specification, Java SE 8 Edition are summarized below. Except for the differences indicated herein, a virtual machine conforming to CLDC 8 shall be compatible with The Java® Virtual Machine Specification, Java SE 8 Edition as specified in [Java SE8] with the clarifications and amendments below.

In case of conflicting information between the present CLDC specification and The Java® Virtual Machine Specification Java SE 8 Edition, the CLDC specification supersedes The Java® Virtual Machine Specification, Java SE 8 Edition.

Clarifications and Amendments to the Java Virtual Machine Specification

A number of features have been eliminated from a Java Virtual Machine conforming to CLDC because the Java libraries included in CLDC are substantially more limited than the class libraries of Java Standard Edition, and/or the presence of those features would have posed security problems in the absence of the full Java SE security model.

Each of the features is discussed in more detail below.

The Structure of the Java Virtual Machine (JVMS8 §2)

ThreadGroups

CLDC does not support ThreadGroups or stopping Threads. The related language in JVMS8 §2.10 is not applicable.

Reflection

CLDC does not support reflection and the special support for reflection in the JVMS8 §2.12 is not applicable.

The Class File Format (JVMS8 §4)

The CLDC Virtual Machine supports class files with version numbers 51 and 52.
Support for class file versions ≤ 48 is optional. Backward compatibility with previous versions of CLDC is achieved by supporting class file versions ≤ 48.

If a class file version is not supported, the CLDC Virtual Machine throws an UnsupportedClassVersionError.

The Constant Pool (JVMS8 §4.4)

The following constant pool entries defined in JVMS8 are not supported; if they are present in a class file this results in a verification error.

Methods (JVMS8 §4.6)

ACC_PRIVATE and ACC_STATIC as a flag on an interface method is not supported and result in a verification error.

Class File Attributes (JVMS8 §4.7)

The following class file attributes defined in JVMS8 are not supported:

Note that these attributes may be present in a valid class file. Class files are required to be well formed enough to permit skipping these attributes.

Class File Verification (JVMS8 §4.10)

Like the Java Virtual Machine of Java SE, a Java Virtual Machine conforming to CLDC must be able to reject invalid class files. This means that a CLDC Virtual Machine must support class file verification.

Class file verification must be implemented as follows:

  1. For class files with version numbers ≥ 51 verification must be performed using Verification by Type Checking as defined in JVMS8 §4.10.1.
  2. For class files with version numbers ≤ 48 verification must be performed using the alternative verification approach as described in CLDC Byte Code Typechecker. If this verification is not supported, class file versions ≤ 48 are not supported. A java.lang.ClassFormatError exception is thrown to report this error.

    Verification by Byte Code Typechecker is optional in CLDC 8 and may be removed in the next release.

  3. Class files with version number 49.* and 50.* cannot be verified by CLDC and are not supported. A java.lang.UnsupportedClassVersionError exception is thrown to report this error.

    Note (Informative): Versions 49.* and 50.* allowed jsr and ret instructions which are not supported by CLDC. Java SE 5 (Version 49.*) did not support the annotations for Verification by Type Checking and is no longer supported. Java SE 6 allowed Verification by Type Inference for version 50 but that is not practical for CLDC.

Loading, Linking and Initializing (JVMS8 §5)

Chapter 5 of JVMS8 applies with the following clarifications:

The resolution of symbolic references to a method handle, a method type and a call site specifier as described in JVMS8 §5.1 is not supported.

The resolution of symbolic references of an invokedynamic as described in JVMS8 §5.4.3 is not supported.

User-defined Class Loaders (§5.3.2)

A Virtual Machine conforming to CLDC does not support user-defined, Java-level class loaders. It shall have a built-in "bootstrap" class loader that cannot be overridden, replaced, or reconfigured. The elimination of user-defined class loaders is part of the security restrictions presented in Sandbox model.

Method Type and Method Handle Resolution (JVMS8 §5.4.3.5)

Method handle resolution, method type resolution, and call site specifier resolution defined in JVMS8 are not supported.

Instruction Set (JVMS8 §6)

Chapter 6 of JVMS8 applies with the following clarifications:

The invokedynamic bytecode is not supported. If the bytecode is found in the classfile, verification fails with java.lang.ClassFormatError .

The invokevirtual bytecode does not support the handling of signature polymorphic methods. These are defined in JVMS8 §2.9. If the argument of invokevirtual is a symbolic reference to a signature polymorphic method, verification fails with java.lang.ClassFormatError .

The ldc and ldc_w bytecodes do not support the handling of method types and method handles (See JVMS8 §5.1). If the argument of ldc or ldc_w is a method type or method handle, verification fails with java.lang.ClassFormatError .


Class File Format and Class Loading

An essential requirement for the Connected Limited Device Configuration is the ability to support dynamic downloading of Java applications and third party content. The dynamic class loading mechanism of the Java platform plays a central role in enabling this. This section discusses the application representation formats and class loading practices required of a virtual machine conforming to CLDC.

Java Archive (JAR) Format Support

A CLDC Virtual Machine must support compressed Java Archive (JAR) files. Detailed information about JAR format is provided at JAR File Format.

Network bandwidth conservation is very important in low-bandwidth wireless networks. The compressed JAR format provides 30 to 50 percent compression over regular class files without loss of any symbolic information or compatibility problems with existing Java systems.

Class File Formats and Versions

A CLDC Virtual Machine must be able to read Java class files in the formats and versions as defined in Class File Verification and distributed as defined by Public Representation of Java Applications and Resources.)

Note (Informative): The class file format numbers used by different JDK versions are as follows:

Public Representation of Java Applications and Resources

A Java application is considered to be "represented publicly" or "distributed publicly" when the system it is stored on is open to the public, and the transport layers and protocols it can be accessed with are open standards. In contrast, a device can be part of a closed network environment where the vendor (such as the operator of a wireless network) controls all communication. In this case, the application is no longer represented publicly once it enters and is distributed via the closed network system.

Whenever Java applications intended for a CLDC device are represented publicly, the compressed JAR file representation format must be used. The JAR file contains classfiles and resources. Class files are individually verified as they are used by the virtual machine.

Additionally, the JAR file may contain application-specific resource files that can be loaded into the virtual machine by calling method Class.getResourceAsStream(String name) (see the CLDC library documentation for details.)

Class File Lookup Order

The Java® Language Specification, Java SE 8 Edition and The Java® Virtual Machine Specification, Java SE 8 Edition do not specify the order in which class files are searched when new class files are loaded into the virtual machine. At the implementation level, a typical Java Virtual Machine utilizes a special environment variable classpath to define the lookup order.

The CLDC Specification assumes class file lookup order to be implementation-dependent, with the restrictions described in the next paragraph. The lookup strategy is typically defined as part of the application management (see Application Management.) A virtual machine conforming to CLDC is not required to support the notion of classpath, but may do so at the implementation level.

Two restrictions apply to class file lookup order. Both these restrictions are important for security reasons:

  1. As explained in Protecting System Classes, a virtual machine conforming to CLDC must guarantee that the application programmer cannot override, modify, or add new system classes (classes belonging to the CLDC API, supported profiles or manufacturer-specific classes) in any way.
  2. The application programmer must not be able to manipulate the class file lookup order in any way.

Implementation Optimizations and Alternative Application Representation Formats

Stripping on Deployment

This Specification therefore permits an Implementation that is packaged together with all of the Java library and application code that will ever run upon it to omit, partially or entirely, elements that are never, under any circumstances, depended upon by that code. The process that creates such an Implementation is called _stripping_, and the resulting Implementation is said to be Stripped.

The elements subject to removal by the stripping process may be Java code, in the form of packages, classes, interfaces, fields, or methods. They may also be other kinds of implementation elements, in the form of static data files or native-code procedures, objects, or libraries.

Constraints: A Stripped Implementation must satisfy the following constraints:

  1. The Implementation provided as input to the stripping process must conform to the Specification. It may implement additional JSR Specifications, in which case stripping may also apply to those components unless explicitly prohibited by their respective Specifications. The input Implementation need not include elements defined as optional by the relevant Specifications.
  2. A Stripped Implementation, once created, cannot be changed. No further elements may be added or removed.
  3. The Java library and application code provided as input to the stripping process may be transformed by that process, but after the process is complete the code cannot be changed. No further code in any form may be added or removed.
  4. A Stripped Implementation is forever bound to the Java library and application code provided as input to the same invocation of the stripping process. A Stripped Implementation may not be used to execute any other library or application code. Elements of a Stripped Implementation may not in any way be referenced by any other library or application code.
  5. The stripping process must preserve the functionality and behavior of the input Implementation and of the input Java library and application code. An element, whether optional or not, that is present in the input Implementation and is used by the input library or application code must also be present in the Stripped Implementation. The library and application code packaged together with a Stripped Implementation must behave identically to the input library and application code running on the input Implementation.
Implementation: This Specification neither mandates nor forbids any particular means of creating Stripped Implementations, so long as the above constraints are satisfied. At a high level, a Stripped Implementation can be created in two steps:
  1. Analyze the combined Implementation, library, and application code to identify elements that are never used, either directly or indirectly.
  2. Remove the unused elements from the combined code and package all of the remaining code into a single binary image.
A precise answer for the first step cannot, in general, be computed automatically since it is equivalent to solving the Halting Problem. Practical tools for creating Stripped Implementations therefore usually rely upon a combination of heuristics, manual analysis, and automatic analysis to compute an approximate answer. It is highly recommended that the binary image created in the second step be fully tested, with the goal of achieving 100% coverage of the remaining library and application code, in order to ensure that all required elements of the Implementation are present.

Preloading/Prelinking ("ROMizing")

A virtual machine conforming to CLDC may choose to preload/prelink some classes. This technology is referred to informally as ROMizing, though it is somewhat misleading, since this technology can be used independently of any specific memory technology. ROMized class files do not necessarily have to be stored in ROM. Typically, small virtual machine implementations choose to preload all the system classes (for instance, classes belonging to a specific configuration or profile), and perform application loading dynamically.

The actual mechanisms for preloading are implementation-dependent and beyond the scope of the CLDC Specification. In all cases, the runtime effect and semantics of preloading/prelinking must be the same as if the actual class had been loaded in at that point. There must be no visible effects from preloading other than the possible speed-up in application launching. In particular, any class initialization that has a user-visible effect must be performed at the time the class would have first been loaded if it had not been preloaded into the system.

Other Implementation-Level Optimizations

Java class files are not optimized for network transport in bandwidth-limited environments. Each Java class file is an independent unit that contains its own constant pool (symbol table), method, field and exception tables, bytecodes, exception handlers, and some other information. The self-contained nature of class files is one of the virtues of Java technology, allowing applications to be composed of multiple pieces that do not necessarily have to reside in the same location, and making it possible to extend applications dynamically at runtime. However, this flexibility has its price. If Java applications were treated as a sealed unit, a lot of space could be saved by removing the redundancies in multiple constant pools and other structures, especially if full symbolic information was left out. Also, one of the desirable features of an application transport format in a limited-power computing environment is the ability to execute applications "in-place," without any special loading or conversion process between the static representation and runtime representation. Standard Java class files are not designed for such execution.

The CLDC Specification mandates the use of compressed JAR files for Java applications that are represented and distributed publicly. However, in closed network environments (see the discussion in Public Representation of Java Applications and Resources.) and internally inside the virtual machine at runtime, alternative formats can be used. For instance, in low-bandwidth wireless networks it is often reasonable to use alternative, more compact transport formats at the network transport level to conserve network bandwidth. Similarly, when storing the downloaded applications in CLDC devices, more compact representations can be used, as long as the observable user-level semantics of the applications remain the same as with the original representation. The alternative formats may not be used for representing or distributing CLDC Java applications publicly, i.e., the public representation format of CLDC Java applications must always be as defined in Public Representation of Java Applications and Resources.

The definition of alternative application representations is assumed to be implementation-dependent and outside the scope of the CLDC Specification.

CLDC 8

Copyright (c) 2013, Oracle and/or its affiliates. All Rights Reserved. Use of this specification is subject to license terms.