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.
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.
CLDC does not support
ThreadGroups or stopping Threads.
The related language in JVMS8 §2.10 is not applicable.
CLDC does not support reflection and the special support for reflection in the JVMS8 §2.12 is not applicable.
If a class file version is not supported, the CLDC Virtual Machine throws an
ACC_PRIVATE and ACC_STATIC as a flag on an interface method is not supported and result in a verification error.
The following class file attributes defined in JVMS8 are not supported:
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:
java.lang.ClassFormatErrorexception is thrown to report this error.
Verification by Byte Code Typechecker is optional in CLDC 8 and may be removed in the next release.
java.lang.UnsupportedClassVersionErrorexception is thrown to report this error.
Note (Informative): Versions 49.* and 50.* allowed
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
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
as described in JVMS8 §5.4.3 is not supported.
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.
invokedynamic bytecode is not supported.
If the bytecode is found in the
classfile, verification fails with
bytecode does not support the handling of signature
polymorphic methods. These are defined in JVMS8 §2.9. If the argument
is a symbolic reference to a signature polymorphic method,
verification fails with
bytecodes do not support the handling of method types and method
handles (See JVMS8 §5.1). If the argument of
is a method type or method handle, verification fails with
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.
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.
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:
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
(see the CLDC library documentation
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:
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:
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.
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.
Copyright (c) 2013, Oracle and/or its affiliates. All Rights Reserved. Use of this specification is subject to license terms.