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.

• For the remainder of this specification, The Java® Virtual Machine Specification, Java SE 8 Edition is referred to as JVMS8. Sections within The Java® Virtual Machine Specification, Java SE 8 Edition are referred to using the § symbol. For example, (JVMS8 §2.4.3).

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 java.lang.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.

• The CONSTANT_MethodHandle_info Structure (JVMS8 §4.4.8)
• The CONSTANT_MethodType_info Structure (JVMS8 §4.4.9)
• The CONSTANT_InvokeDynamic_info Structure (JVMS8 §4.4.10)

Methods (JVMS8 §4.6)

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

In a class file whose version number is less than or equal to 52.0, each method of an interface must have its ACC_PUBLIC and ACC_ABSTRACT flags set. Non-abstract interface methods are 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:

• The Synthetic attribute (JVMS8 §4.7.8)
• The Signature attribute (JVMS8 §4.7.9)
• The SourceFile attribute (JVMS8 §4.7.10)
• The SourceDebugExtension attribute (JVMS8 §4.7.11)
• The LineNumberTable attribute (JVMS8 §4.7.12)
• The LocalVariableTable attribute (JVMS8 §4.7.13)
• The LocalVariableTypeTable attribute (JVMS8 §4.7.14)
• The Deprecated attribute (JVMS8 §4.7.15)
• The RuntimeVisibleAnnotations attribute (JVMS8 §4.7.16)
• The RuntimeInvisibleAnnotations attribute (JVMS8 §4.7.17)
• The RuntimeVisibleParameterAnnotations attribute (JVMS §4.7.18)
• The RuntimeInvisibleParameterAnnotations attribute (JVMS §4.7.19)
• The RuntimeVisibleTypeAnnotations attribute (JVMS8 §4.7.20)
• The RuntimeInvisibleTypeAnnotations attribute (JVMS8 §4.7.21)
• The AnnotationDefault attribute (JVMS8 §4.7.22)
• The BootstrapMethod attribute (JVMS8 §4.7.23)
• The MethodParameters Attribute (JVMS8 §4.7.24)

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 specified in CLDC Byte Code Typechecker. If class file versions ≤ 48 are not supported, a java.lang.ClassFormatError exception is thrown.

   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:

• The 45.* (usually 45.3) version number identifies Java SE 1.1 class files.
• The 46.0 version number identifies Java SE 1.2 class files.
• The 47.0 version number identifies Java SE 1.3 class files.
• The 48.0 version number identifies Java SE 1.4 class files.
• The 49.0 version number identifies Java SE 5 class files.
• The 50.0 version number identifies Java SE 6 class files.
• The 51.0 version number identifies JAVA SE 7 class files.
• The 52.0 version number identifies Java SE 8 class files.

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

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.