Programming Wireless Devices with the Java2 Platform
| [ directory ] |
|
4.4 Java Virtual Machine Specification CompatibilityThe general goal for a virtual machine conforming to CLDC is to be as compliant with the Java™ Virtual Machine Specification as is possible within strict memory constraints of CLDC target devices. This section summarizes the differences between a virtual machine conforming to CLDC and the Java Virtual Machine of Java 2 Standard Edition (J2SE). Except for the differences indicated herein, a virtual machine conforming to CLDC is compatible with the Java Virtual Machine as specified in the The Java™ Virtual Machine Specification, Second Edition by Tim Lindholm and Frank Yellin. Addison-Wesley, 1999, ISBN 0-201-43294-3. Note For the remainder of this book, the Java™ Virtual Machine Specification is referred to as JVMS. Sections within the Java™ Virtual Machine Specification are referred to using the § symbol. For example, (JVMS §2.4.3). 4.4.1 Features Eliminated from the Virtual MachineA number of features have been eliminated from a virtual machine conforming to CLDC because the Java libraries included in CLDC are substantially more limited than libraries in Java 2 Standard Edition, and/or the presence of those features would have posed security problems in the absence of the full J2SE security model. The eliminated features include:
In addition, a virtual machine conforming to CLDC has a significantly more limited set of error classes than a full J2SE virtual machine. Applications written to conform to the Connected, Limited Device Configuration shall not rely on any of the features above. Each of the features in this list is discussed in more detail next. User-defined class loadersA virtual machine conforming to CLDC does not support user-defined, Java-level class loaders (JVMS §5.3, §2.17.2). A virtual machine conforming to CLDC has 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 of the CLDC Specification. Thread groups and daemon threadsA virtual machine conforming to CLDC implements multithreading, but does not have support for thread groups or daemon threads (JVMS §2.19, §8.12). Thread operations such as starting of threads can be applied only to individual thread objects. If application programmers want to perform thread operations for groups of threads, explicit collection objects (such as instances of classes Hashtable or Vector) must be used at the application level to store the thread objects. Finalization of class instancesCLDC libraries do not include the method java.lang.Object.finalize(). Therefore, a virtual machine conforming to CLDC does not support finalization of class instances (JVMS §2.17.7). No application built to conform to the Connected, Limited Device Configuration can require that finalization be available. Errors and asynchronous exceptionsAs discussed earlier in Section 4.3.2, "Error-Handling Limitations," the error-handling capabilities of a virtual machine conforming to CLDC are limited. A virtual machine conforming to CLDC supports the set of Error classes defined in Section 5.2, "Classes Derived from Java 2 Standard Edition." When encountering any other error, the implementation shall behave as follows:
If the virtual machine conforming to CLDC implements additional error checks that are part of the Java™ Virtual Machine Specification but that are not required by the CLDC Specification, the implementation will throw the nearest CLDC-supported superclass of the Error class that is defined by the Java™ Virtual Machine Specification. A virtual machine conforming to CLDC generally supports exception handling as defined by Java™ Virtual Machine Specification. However, a virtual machine conforming to CLDC does not support asynchronous exceptions (JVMS §2.16.1). 4.4.2 Class File VerificationLike the Java Virtual Machine of Java 2 Standard Edition, a virtual machine conforming to CLDC must be able to reject invalid class files. However, since the static and dynamic memory footprint of the standard class file verifier is excessive for a typical CLDC target device, an alternative solution is defined in the CLDC Specification. This solution is described below. Off-device preverification and runtime verification with stack mapsThe existing J2SE class file verifier defined in the Java™ Virtual Machine Specification (JVMS §4.9) is not ideal for small, resource-constrained devices. The J2SE verifier takes a minimum of 50 kilobytes of binary code space and typically at least 30 to 100 kilobytes of dynamic RAM at run time. In addition, the CPU power needed to perform the complex dataflow algorithm in the conventional verifier can be substantial. The verification approach described in this subsection is significantly smaller and more efficient in resource-constrained devices than the existing J2SE verifier. The implementation of the new verifier in Sun's CLDC reference implementation requires about 12 kilobytes of Intel x86 binary code and less than 100 bytes of dynamic RAM at run time for typical class files. The verifier performs only a linear scan of the bytecode, without the need of a costly dataflow algorithm. The CLDC class file verifier operates in two phases, as depicted in Figure 4.2.
Figure 4.2. Two-phase class file verification in CLDC
Runtime class file verification guarantees type safety. Classes that pass the runtime verifier cannot, for example, violate the type system of the Java virtual machine or corrupt the memory. Unlike approaches based on code signing, such a guarantee does not rely on the predefined verification information to be authentic or trusted. A missing, incorrect, or corrupted StackMap attribute causes the class to be rejected by the runtime verifier. The new verifier requires the methods in class files to contain a special StackMap attribute. The preverifier tool inserts this attribute into normal class files. A transformed class file is still a valid Java class file, with additional StackMap attributes (refer to the CLDC Specification for further details) that allow verification to be carried out efficiently at run time. These attributes are automatically ignored by the conventional class file verifier used in Java 2 Standard Edition, so the solution is fully upward compatible with the Java Virtual Machine of Java 2 Standard Edition. Preprocessed class files containing the extra attributes are approximately 5 to 15 percent larger than the original, unmodified class files. Additionally, the new verifier requires that all the subroutines in the bytecodes of class files are inlined. In Java class files, subroutines are special bytecode sequences that contain the bytecodes jsr, jsr_w, ret, or wide ret. The inlining process removes all the jsr, jsr_w, ret, and wide ret bytecodes from all the methods in class files, replacing these instructions with semantically equivalent bytecode. The inlining process makes runtime verification significantly easier and faster. The new verification process and the format of the StackMap attribute have been specified in more detail in the CLDC Specification. 4.4.3 Class File Format and Class LoadingAn 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 this. This section discusses the application representation formats and class loading practices required of a virtual machine conforming to CLDC. Supported file formatsA CLDC implementation must be able to read standard class files (defined in JVMS Chapter 4) with the preverification changes discussed above. In addition, a CLDC implementation must support compressed Java Archive (JAR) files. Detailed information about the JAR format is provided at http://java.sun.com/products/jdk/1.2/docs/guide/jar/. 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 implementation must be able to read Java class files in all the formats supported by Java 2 Platform Standard Edition, JDK versions 1.1, 1.2, 1.3, and 1.4. Note The class file formats used by different JDK versions are as follows[2] :
A virtual machine conforming to CLDC should be able to read Java class files in any of the formats listed above. However, the virtual machine is allowed to ignore certain class file attributes that the CLDC implementation does not need. More specifically, the following attributes can be ignored by a CLDC implementation:
Public representation of Java applications and resourcesA 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 must contain regular class files with the following restrictions and additional requirements:
Sun's CLDC reference implementation includes a preverification tool for performing these modifications to a class file. The stack map attributes are automatically ignored by the conventional class file verifier described in JVMS §4.9. That is, the modified class file format is fully upward compatible with other Java environments such as J2SE or J2EE. 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). Class file lookup orderThe Java™ Language Specification and Java™ Virtual Machine Specification 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 virtual machine implementation uses the 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 implementation (see Section 4.2.4, "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. First, a virtual machine conforming to CLDC must guarantee that the application programmer cannot override, modify, or add new system classes (classes belonging to CLDC, profiles, or other libraries) in any way. Second, it is required that the application programmer must not be able to manipulate the class file lookup order in any way. Both of these restrictions are important for security reasons. Implementation optimizationsThe 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 above) and internally inside the virtual machine at run time, alternative application representation formats can be used. For instance, in low-bandwidth wireless networks it is often advised to use alternative, more compact transport formats at the network transport level to conserve network bandwidth. Similarly, when storing the downloaded applications in devices, more compact representations can be used as long as the observable user-level semantics of the applications remain the same as with the public representation required by the CLDC Specification. The definition of more compact class file representations is assumed to be implementation-dependent and outside the scope of the CLDC Specification. Preloading/prelinking ("ROMizing")A virtual machine conforming to CLDC may choose to preload and prelink some classes to reduce class loading time at run time. This technology is often referred to informally as ROMizing.[3]
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 first have been used if it had not been preloaded into the system. Application representation format optimizationsJava class files are not optimized for network transport in limited bandwidth 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, making it possible to extend applications dynamically at run time. 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. The CLDC Specification allows the use of such formats at the implementation level as long as the public application representation and the publicly observable semantics of the CLDC implementation remain the same as with the original representation required by the CLDC Specification. The definition of alternative application representation formats is implementation-dependent and outside the scope of the CLDC Specification. |
| [ directory ] |
|