Virtual Machine Specification, Java Card Platform, v3.0.1, Connected Edition

The general goal for a virtual machine conforming to the Java Card platform is to be as compliant with the Java Virtual Machine Specification as possible within the strict memory constraints of Java Card platform target devices. This chapter summarizes the differences between a virtual machine conforming to the Java Card platform and the Java virtual machine of the Java SE platform. Except for the differences indicated herein, a virtual machine conforming to the Java Card platform MUST be compatible with the Java virtual machine as specified in the Java Virtual Machine Specification (Java Series), Second Edition by Tim Lindholm and Frank Yellin (Addison-Wesley, 1999), ISBN 0-201-43294-3 and as amended by Java Virtual Machine Specification (JVMS) for Java 5 and by the Java Development Kit, Version 1.6 revisions to chapter 4 (Class File Format) of Java Virtual Machine Specification.

---

5.1 No Floating Point Support

A Java virtual machine supporting the Java Card Platform does not have floating point support. Floating point support was removed because the majority of Java Card Platform target devices do not have hardware floating point support, and since the cost of supporting floating point in software was considered too high. Consequently, a Java virtual machine supporting the Java Card Platform shall not support the bytecodes listed in TABLE 5-1:

fconst_0, fconst_1, fconst_2, dconst_0, dconst_1

fload, fload_x, dload, dload_x

fstore, fstore_x, dstore, dstore_x

faload, daload, fastore, dastore, newarray T_DOUBLE,newarray T_FLOAT

fadd, dadd, fsub, dsub, fmul, dmul,fdiv, ddiv, frem, drem, fneg, dneg, fcmpl, fcmpg, dcmpl,dcmpg

i2f, f2i, i2d, d2i, l2f, l2d, f2l, d2l, f2d, d2f

freturn, dreturn

All user-supplied classes and methods running on top of a Java virtual machine supporting the Java Card Platform must satisfy the following constraints:

• No method shall use any of the above forbidden bytecodes.
• No field can have as its type float or double, or an array of one of those types.
• No method can have an argument or return type of type float or double or an array whose component type is float or double.
• No constant pool entry can be of type CONSTANT_Float or CONSTANT_Double.
• No constant pool entry can be of type CONSTANT_Class in which the class is an array of type float or double.

Due to the lack of floating point support, the following sections and subsections of the Java Virtual Machine Specification (JVMS) are not applicable to a Java virtual machine supporting the Java Card Platform: §2.4.3, §2.4.4, §2.18, §3.3.2 and §3.8. In addition, all the other parts of the JVMS that refer to floating point data types (float or double) or operations are beyond the scope of this Runtime Environment Specification, Java Card Platform, Version 3.0.1, Connected Edition.

---

5.2 Features Eliminated from the Virtual Machine

A number of features have been eliminated from a virtual machine conforming to the Java Card platform because the Java libraries included in the Java Card platform are substantially more limited than the class libraries of Java SE platform and/or the presence of those features would have posed security problems in the absence of the full Java SE platform security model. The eliminated features include:

• User-defined class loaders (JVMS §5.3.2)
• Thread groups and daemon threads (JVMS §2.19, §8.12)
• Finalization of class instances (JVMS §2.17.7)
• Asynchronous exceptions (JVMS §2.16.1)

In addition, a virtual machine conforming to the Java Card platform has a significantly more limited set of error classes than a full Java SE platform virtual machine.

Applications written for the Java Card platform MUST not rely on any of the features above. Each of the features in this list is discussed in more detail below.

5.2.1 User-Defined Class Loaders

A virtual machine conforming to the Java Card platform does not support user-defined, Java platform-level class loaders (JVMS §5.3, §2.17.2). A virtual machine conforming to the Java Card platform MUST use platform defined class loaders that cannot be overridden, replaced, or reconfigured. The platform managed class loader hierarchy used by the Java Card platform is described in Runtime Environment Specification, Connected Edition. The elimination of user-defined class loaders is part of the security restrictions presented in Section 3.3.2.1, Sandbox Model.

5.2.2 Thread Groups and Daemon Threads

A virtual machine conforming to the Java Card platform implements multithreading, but does not have support for thread groups or daemon threads (JVMS §2.19, §8.12). Thread operations such as starting threads can be applied only to individual thread objects. If application programmers want to perform thread operations for groups of threads, explicit collection objects must be used at the application level to store the thread objects.

5.2.3 Finalization of Class Instances

Java Card platform libraries do not include the method Object.finalize(). Therefore, a virtual machine conforming to the Java Card platform does not support finalization of class instances (JVMS §2.17.7). No application running on top of a virtual machine conforming to the Java Card platform shall require that finalization be available.

5.2.4 Errors and Asynchronous Exceptions

As discussed earlier in Section 4.3, Exception and Error Handling Limitations, the error handling capabilities of a virtual machine conforming to the Java Card platform are limited.

A virtual machine conforming to the Java Card platform MUST support the set of Error classes defined in Section 6.2, Classes Derived from Java SE Platform. When encountering any other error, the implementation MUST behave in one of the following ways:

• The virtual machine halts in an implementation-specific manner.
• The virtual machine throws an Error that is the nearest Java Card platform-supported superclass of the Error class representing the error condition that must be thrown according to the Java Virtual Machine Specification.

If the virtual machine conforming to the Java Card platform implements additional error checks that are part of the Java Virtual Machine Specification but that are not required by the Virtual Machine Specification, Java Card Platform, v3.0.1, Connected Edition, the implementation MUST throw the nearest Java Card platform-supported superclass of the Error class representing the error condition that is defined by the Java Virtual Machine Specification.

A virtual machine conforming to the Java Card platform MUST generally support exception handling as defined by Java Virtual Machine Specification. However, a virtual machine conforming to the Java Card platform does not support asynchronous exceptions (JVMS §2.16.1).

---

5.3 Class File Verification

Like the Java virtual machine of the Java SE platform, a virtual machine conforming to the Java Card platform must be able to reject invalid class files. This means that a Java Card platform implementation must support class file verification.

Class file verification in the Java Card platform MUST be implemented using the type checking approach based on the StackMapTable attribute defined in the The Java Development Kit, Version 1.6 revisions to chapter 4 (Class File Format) of Java Virtual Machine Specification (JVMS §4.11). But, unlike JDK version 1.6 on the Java SE platform, if the type checking fails on the Java Card platform, the class file MUST be rejected.

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 verification attribute to be authentic or trusted. A missing, incorrect or corrupted verification attribute causes the class to be rejected by the runtime verifier.

---

5.4 Class File Format and Class Loading

An essential requirement for the Java Card platform 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 the Java Card platform.

5.4.1 Supported File Formats

A Java Card platform implementation must be able to read standard Java class files (defined in JVMS Chapter 4). In addition, a Java Card platform implementation must support compressed JAR files. Detailed information about the JAR file format is provided at http://java.sun.com/javase/6/docs/technotes/guides/jar/. The Java Card application distribution units using JAR files are described in Runtime Environment Specification, Connected Edition.

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

A Java Card platform implementation must be able to read Java class files in the format supported by Java SE platform, JDK version 1.6.

A virtual machine conforming to the Java Card platform should be able to read Java class files in the formats listed above. However, the virtual machine is allowed to ignore certain class file attributes, which the Java Card platform implementation does not need. More specifically, the following attributes can be ignored by a Java Card platform implementation:

• The Synthetic attribute (JVMS §4.7.6)
• The SourceFile attribute (JVMS §4.7.7)
• The LineNumberTable attribute (JVMS §4.7.8)
• The LocalVariableTable attribute (JVMS §4.7.9)
• The Deprecated attribute (JVMS §4.7.10)
• The EnclosingMethod attribute (JVMS §4.8.6)
• The Signature attribute (JVMS §4.4.4)
• The LocalVariableTypeTable attribute (JVMS §4.8.13)
• The RuntimeVisibleAnnotations attribute (JVMS §4.8.15)
• The RuntimeInvisibleAnnotations attribute (JVMS §4.8.16) for annotations not defined by the Runtime Environment Specification, Connected Edition
• The RuntimeVisibleParameterAnnotations attribute (JVMS §4.8.17)
• The AnnotationDefault attribute (JVMS 4.8.19)
• The RuntimeInvisibleParameterAnnotations attribute (JVMS §4.8.18) for annotations not defined by the Runtime Environment Specification, Connected Edition

For historical reasons (JVMS p. 127), a virtual machine conforming to the Java Card platform is not required to check that the InnerClasses attribute (JVMS §4.7.5) is well-formed.

5.4.2 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 that can access it 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 Java Card platform device are represented publicly, the compressed JAR file representation format must be used. The JAR file must contain JDK version 1. 6 format class files, as defined in The Java Development Kit, Version 1.6 revisions to chapter 4 (Class File Format) of Java Virtual Machine Specification.

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 Java Card platform library documentation for details.

5.4.3 Class File Lookup Order

The 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 Java virtual machine implementation utilizes a special environment variable classpath to define the lookup order.

This Virtual Machine Specification, Java Card Platform, v3.0.1, Connected Edition assumes class file lookup order to be based on the standard manifest file attribute, Class-Path with the restrictions described in the next paragraph. The lookup strategy is typically defined as part of the application management implementation (see Section 3.2, Application Management.)

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

• As explained in Section 3.3.2.2, Protecting System Classes, a virtual machine conforming to the Java Card platform must guarantee that the application programmer cannot override, modify, or add new system classes (classes belonging to the Java Card platform, core platform, Java Card framework or market-specific extension libraries or manufacturer-specific classes) in any way.
• The application programmer must not be able to manipulate the class file lookup order of system classes or other previously installed extension library classes in any way.

5.4.4 Implementation Optimizations and Alternative Application Representation Formats

Preloading/prelinking (“ROMizing”) - A virtual machine conforming to the Java Card platform may choose to preload/prelink some classes. This technology is referred to informally as ROMizing.^[1] Typically, small virtual machine implementations choose to preload all the system classes and perform application loading dynamically.

The actual mechanisms for preloading are implementation-dependent and beyond the scope of the Virtual Machine Specification, Java Card Platform, v3.0.1, Connected Edition. 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, 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 Virtual Machine Specification, Java Card Platform, v3.0.1, Connected Edition 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 Section 5.4.2, Public Representation of Java Applications and Resources) and 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 downloaded applications in Java Card platform compliant smart card devices, more compact representations can be used, as long as the observable user-level semantics of the applications remain the same as the original representation. The alternative formats may not be used for representing or distributing Java Card applications publicly (i.e., the public representation format of Java Card applications must always be as defined in Section 5.4.2, 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 Virtual Machine Specification, Java Card Platform, v3.0.1, Connected Edition.

^{1 (Footnote) The term ROMizing 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 read-only- memory (ROM).}

Virtual Machine Specification, Java Card Platform, v3.0.1, Connected Edition

5-30-09

Copyright © 2009 Sun Microsystems, Inc. All rights reserved.