|
|
This chapter describes the subset of the Java virtual machine and language that is supported in the Java Card platform, version 2.2.1.
It would be ideal if programs for smart cards could be written using all of the Java programming language, but a full implementation of the Java virtual machine is far too large to fit on even the most advanced resource-constrained devices available today.
A typical resource-constrained device has on the order of 1.2K of RAM, 16K of non-volatile memory (EEPROM or flash) and 32K of ROM. The code for implementing string manipulation, single and double-precision floating point arithmetic, and thread management would be larger than the ROM space on such a device. Even if it could be made to fit, there would be no space left over for class libraries or application code. RAM resources are also very limited. The only workable option is to implement Java Card technology as a subset of the Java platform.
Applets written for the Java Card platform are written in the Java programming language. They are compiled using Java compilers. Java Card technology uses a subset of the Java language, and familiarity with the Java platform is required to understand the Java Card platform.
The items discussed in this section are not described to the level of a language specification. For complete documentation on the Java programming language, see The Java Language Specification.
The items listed in this section are elements of the Java programming language and platform that are not supported by the Java Card platform.
Dynamic class loading is not supported in the Java Card platform. An implementation of the Java Card platform is not able to load classes dynamically. Classes are either masked into the card during manufacturing or downloaded through an installation process after the card has been issued. Programs executing on the card may only refer to classes that already exist on the card, since there is no way to download classes during the normal execution of application code.
Security management in the Java Card platform differs significantly from that of the Java platform. In the Java platform, there is a Security Manager class (java.lang.SecurityManager) responsible for implementing security features. In the Java Card platform, language security policies are implemented by the virtual machine. There is no Security Manager class that makes policy decisions on whether to allow operations.
Finalization is also not supported. finalize() will not be called automatically by the Java Card virtual machine.
The Java Card virtual machine does not support multiple threads of control. Programs for the Java Card platform (“Java Card programs”) cannot use class Thread or any of the thread-related keywords in the Java programming language.
The Java Card platform does not support cloning of objects. Java Card API class Object does not implement a clone method, and there is no Cloneable interface provided.
The Java Card platform language subset supports the package access control defined in the Java language. However, the cases that are not supported are as follows.
The following keywords indicate unsupported options related to native methods, threads, floating point, and memory management.
The Java Card platform does not support types char, double, float and long. It also does not support arrays of more than one dimension.
In general, none of the Java core API classes are supported in the Java Card platform. Some classes from the java.lang package are supported (see Section 2.2.2.4 “Classes”), but none of the rest are. For example, classes that are not supported are String, Thread (and all thread-related classes), wrapper classes such as Boolean and Integer, and class Class.
Class java.lang.System is not supported. Java Card technology supplies a class javacard.framework.JCSystem, which provides an interface to system behavior.
If a language feature is not explicitly described as unsupported, it is part of the supported subset. Notable supported features are described in this section.
Software written for the Java Card platform follows the standard rules for the Java platform packages. Java Card API classes are written as Java source files, which include package designations. Package mechanisms are used to identify and control access to classes, static fields and static methods. Except as noted in “Access Control in Java Packages” (Section 2.2.1.1 “Unsupported Features”), packages in the Java Card platform are used exactly the way they are in the Java platform.
The Java Card platform programs supports dynamically created objects, both class instances and arrays. This is done, as usual, by using the new operator. Objects are allocated out of the heap.
A Java Card virtual machine will not necessarily garbage collect objects. Any object allocated by a virtual machine may continue to exist and consume resources even after it becomes unreachable. See section Section 2.2.3.2 “Object Deletion Mechanism” for more information regarding support for an optional object deletion mechanism.
Since Java Card technology-based objects (“Java Card objects”) are Java programming language objects, invoking virtual methods on objects in a program written for the Java Card platform is exactly the same as in a program written for the Java platform. Inheritance is supported, including the use of the super keyword.
Java Card API classes may define or implement interfaces as in the Java programming language. Invoking methods on interface types works as expected. Type checking and the instanceof operator also work correctly with interfaces.
Java Card programs may define, throw and catch exceptions, as in Java programs. Class Throwable and its relevant subclasses are supported. Some Exception and Error subclasses are omitted, since those exceptions cannot occur in the Java Card platform. See Section 2.3.3 “Exceptions” for specification of errors and exceptions.
The following keywords are supported. Their use is the same as in the Java programming language.
Java programming language types boolean, byte, short, and int are supported. Objects (class instances and single-dimensional arrays) are also supported. Arrays can contain the supported primitive data types, objects, and other arrays.
Some Java Card implementations might not support use of the int data type. (Refer to Section 2.2.3.1 “Integer Data Type”)
Most of the classes in the java.lang package are not supported on the Java Card platform. The following classes from java.lang are supported on the card in a limited form.
Java Card API classes descend from java.lang.Object, just as in the Java programming language. Most of the methods of Object are not available in the Java Card API, but the class itself exists to provide a root for the class hierarchy.
Class Throwable and its subclasses are supported. Most of the methods of Throwable are not available in the Java Card API, but the class itself exists to provide a common ancestor for all exceptions.
This section describes the optional features of the Java Card platform. An optional feature is not required to be supported in a Java Card platform-compatible implementation. However, if an implementation does include support for an optional feature, it must be supported fully, and exactly as specified in this document.
The int keyword and 32-bit integer data type need not be supported in a Java Card implementation. A Java Card virtual machine that does not support the int data type will reject programs which use the int data type or 32-bit intermediate values.
The result of an arithmetic expression produced by a Java Card virtual machine must be equal to the result produced by a Java virtual machine, regardless of the input values. A Java Card virtual machine that does not support the int data type must reject expressions that could produce a different result.
Java Card technology, version 2.2.1 offers an optional, object deletion mechanism. Applications designed to run on these implementations can use the facility by invoking the appropriate API. See Application Programming Interface for the Java Card™ Platform, Version 2.2.1. But, the facility is only suitable for updating large objects such as certificates and keys atomically. Therefore, application programmers should conserve on the allocation of objects.
The limitations of resource-constrained hardware prevent Java Card virtual machines from supporting the full range of functionality of certain Java platform features. The features in question are supported, but a particular virtual machine may limit the range of operation to less than that of the Java platform.
To ensure a level of portability for application code, this section establishes a minimum required level for partial support of these language features.
The limitations here are listed as maximums from the application programmer’s perspective. Java packages that do not violate these maximum values can be converted into Java Card technology-based CAP files (“Java Card CAP files”), and will be portable across all Java Card implementations. From the Java Card virtual machine implementer’s perspective, each maximum listed indicates a minimum level of support that will allow portability of applets.
A package can reference at most 128 other packages.
The fully qualified name of a package may contain a maximum of 255 characters. The package name size is further limited if it contains one or more characters which, when represented in UTF-8 format, requires multiple bytes.
A package can contain at most 255 classes and interfaces.
A class can implement at most 15 interfaces, including interfaces implemented by superclasses.
An interface can inherit from at most 14 superinterfaces.
A class in an applet package can have at most 256 public or protected static non-final fields. A class in a library package can have at most 255 public or protected static non-final fields. There is no limit on the number of static final fields (constants) declared in a class.
A class in an applet package can have at most 256 public or protected static methods. A class in a library package can have at most 255 public or protected static methods.
A class can implement a maximum of 128 public or protected instance methods, and a maximum of 128 instance methods with package visibility. These limits include inherited methods.
Class instances can contain a maximum of 255 fields, where an int data type is counted as occupying two fields. These limits include inherited fields.
Arrays can hold a maximum of 32767 fields.
The maximum number of variables that can be used in a method is 255. This limit includes local variables, method parameters, and, in the case of an instance method invocation, a reference to the object on which the instance method is being invoked (i.e. this). An int data type is counted as occupying two local variables.
A method can have at most 32767 Java Card virtual machine bytecodes. The number of Java Card technology-based bytecodes (“Java Card bytecodes”) may differ from the number of Java bytecodes in the Java virtual machine implementation of that method.
The maximum depth of an operand stack associated with a method is 255 16-bit cells.
The format of the Java Card virtual machine switch instructions limits switch statements to a maximum of 65536 cases. This limit is far greater than the limit imposed by the maximum size of methods (Section 2.2.4.4 “Methods”).
The Java Card virtual machine contains limited support for class initialization because there is no general mechanism for executing <clinit> methods. Support for <clinit> methods is limited to the initialization of static field values with the following constraints:
<clinit> method.
Primitive constant data types include boolean, byte, short, and int.
Given Java source files that adhere to these language-level constraints on static field initialization, it is expected that reasonable Java compilers will:
iconst_[m1,0-5], [b|s]ipush, ldc, ldc_w, aconst_nullnewarray([byte|short|boolean|int] )dup[b|i|s]astore, putstaticreturn
Applets that implement the javacard.framework.Multiselectable interface are called multiselectable applets. For more details on multiselection, please see the Runtime Environment Specification for the Java Card™ Platform, Version 2.2.1.
All applets within a package shall be multiselectable, or none shall be.
This section defines the subset of the RMI system that is supported by Java Card platform RMI (“Java Card RMI”).
A class is remote if it or any of its superclasses implements a remote interface.
A remote interface is an interface which satisfies the following requirements:
java.rmi.Remote or the interface extends, directly or indirectly, the interface java.rmi.Remote. java.rmi.RemoteException (or one of its superclasses) in its throws clause.In addition, Java Card RMI imposes additional constraints on the definition of remote methods. These constraints are as a result of the Java Card platform language subset and other feature limitations. For more information, see sections Section 2.2.6.2 “Access Control of Remote Interfaces” and Section 2.2.6.3 “Parameters and Return Values”.
The Java RMI system supports the package access control defined in the Java language. However, Java Card RMI does not support package-visible remote interfaces.
The parameters of a remote method must only include parameters of the following types:
boolean, byte, short, int),boolean[], byte[], short[], int[]).The return type of a remote method must only be one of the following types:
boolean, byte, short, int),boolean[], byte[], short[], int[]),voidJava Card technology uses a subset of the Java virtual machine, and familiarity with the Java platform is required to understand the Java Card virtual machine.
The items discussed in this section are not described to the level of a virtual machine specification. For complete documentation on the Java virtual machine, refer to the The Java™ Virtual Machine Specification.
The operation of the Java Card virtual machine can be defined in terms of standard Java platform class files. Since the Java Card virtual machine supports only a subset of the behavior of the Java virtual machine, it also supports only a subset of the standard class file format.
Field descriptors may not contain BaseType characters C, D, F or J. ArrayType descriptors for arrays of more than one dimension may not be used.
Constant pool table entries with the following tag values are not supported.
|
Constant Type
|
Value
|
|||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
CONSTANT_String
|
8
|
|||||||||||||
CONSTANT_Float
|
4
|
|||||||||||||
CONSTANT_Long
|
5
|
|||||||||||||
CONSTANT_Double
|
6
|
|||||||||||||
In field_info structures, the access flags ACC_VOLATILE and ACC_TRANSIENT are not supported.
In method_info structures, the access flags ACC_SYNCHRONIZED, ACC_STRICT, and ACC_NATIVE are not supported.
All items in the ClassFile structure are supported.
Field descriptors may contain BaseType characters B, I, S and Z, as well as any ObjectType. ArrayType descriptors for arrays of a single dimension may also be used.
All forms of method descriptors are supported.
Constant pool table entry with the following tag values are supported.
In field_info structures, the supported access flags are ACC_PUBLIC, ACC_PRIVATE, ACC_PROTECTED, ACC_STATIC and ACC_FINAL.
The remaining components of field_info structures are fully supported.
In method_info structures, the supported access flags are ACC_PUBLIC, ACC_PRIVATE, ACC_PROTECTED, ACC_STATIC, ACC_FINAL and ACC_ABSTRACT.
The remaining components of method_info structures are fully supported.
The attribute_info structure is supported. The Code, ConstantValue, Exceptions, LocalVariableTable, Synthetic, InnerClasses, and Deprecated attributes are supported.
The following sections detail the bytecodes that are either supported or unsupported in the Java Card platform. For more details, refer to Chapter 7, “Java Card Virtual Machine Instruction Set”.
A class file must conform to the following restrictions on the static form of bytecodes.
The ldc and ldc_w bytecodes can only be used to load integer constants. The constant pool entry at index must be a CONSTANT_Integer entry. If a program contains an ldc or ldc_w instruction that is used to load an integer value less than
-32768 or greater than 32767, that program will require the optional int instructions (Section 2.2.3.1 “Integer Data Type”).
The value of the npairs operand must be less than 65536. This limit is far greater than the limit imposed by the maximum size of methods (Section 2.2.4.4 “Methods”). If a program contains a lookupswitch instruction that uses keys of type int, that program will require the optional int instructions (Section 2.2.3.1 “Integer Data Type”). Otherwise, key values must be in the range
-32768 to 32767.
The bytecode can contain at most 65536 cases. This limit is far greater than the limit imposed by the maximum size of methods (Section 2.2.4.4 “Methods”). If a program does not use the optional int instructions (Section 2.2.3.1 “Integer Data Type”), the values of the high and low operands must both be at least -32768 and at most 32767.
The wide bytecode can only be used with an iinc instruction.
The Java Card platform provides full support for the Java platform’s exception mechanism. Users can define, throw and catch exceptions just as in the Java platform. The Java Card platform also makes use of the exceptions and errors defined in The Java Language Specification. An updated list of the Java platform’s exceptions is provided in the JDK documentation.
Not all of the Java platform’s exceptions are supported in the Java Card platform. Exceptions related to unsupported features are naturally not supported. Class loader exceptions (the bulk of the checked exceptions) are not supported.
Note that some exceptions may be supported to the extent that their error conditions are detected correctly, but classes for those exceptions will not necessarily be present in the API.
The supported subset is described in the tables below.
In the Java platform, uncaught exceptions and errors will cause the virtual machine’s current thread to exit. As the Java Card virtual machine is single-threaded, uncaught exceptions or errors will cause the virtual machine to halt. Further response to uncaught exceptions or errors after halting the virtual machine is an implementation-specific policy, and is not mandated in this document.
Some error conditions are known to be unrecoverable at the time they are thrown. Throwing a runtime exception or error that cannot be caught will also cause the virtual machine to halt. As with uncaught exceptions, implementations may take further responses after halting the virtual machine. Uncatchable exceptions and errors which are supported by the Java Card platform may not be reflected in the Java Card API, though the Java Card platform will correctly detect the error condition.
|
|
Virtual Machine Specification for the Java Card Platform Specification, 2.2.1 |
Copyright © 2003 Sun Microsystems, Inc. All rights reserved.