(from Chapter 2 of the Java Card Virtual Machine Specification)[1]
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 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.
Java Card technology does not require a garbage collector. Nor does Java Card technology allow explicit deallocation of objects, since this would break the Java programming language's required pointer-safety. Therefore, application programmers cannot assume that objects that are allocated are ever deallocated. Storage for unreachable objects will not necessarily be reclaimed.
Finalization is also not required. finalize() will not necessarily be called automatically by the Java Card virtual machine, and programmers should not rely on this behavior.
The Java Card virtual machine does not support multiple threads of control. 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 language subset supports the package access control defined in the Java language. However, the cases that are not supported are as follows.
If a class implements a method with
packageaccess visibility, a subclass cannot override the method and change the access visibility of the method toprotectedorpublic.An interface that is defined with
packageaccess visibility cannot be extended by an interface withpublicaccess visibility.A
publicorprotectedmethod in apublicclass cannot contain a formal parameter of type reference to apackage-visibleclass.A
package-visibleclass that is extended by apublicclass cannot define anypublicorprotectedmethods.
The following keywords indicate unsupported options related to native methods, threads and memory management.
native
| synchronized
| transient
| volatile
|
The Java Card platform does not support types char, double, float or long, or operations on those types. 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 A.2.4), 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.
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” (A.1.1), 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.
As noted in “Garbage Collection & Finalization” (Section A.1.1), 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.
Since 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 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 the Java Card Virtual Machine Specification section 2.3.3 for specification of errors and exceptions.)
The following keywords are supported. Their use is the same as in the Java programming language.
abstract
| default
| if
| private
| this
|
boolean
| do
| implements
| protected
| throw
|
break
| else
| import
| public
| throws
|
byte
| extends
| instanceof
| return
| try
|
case
| final
| int
| short
| void
|
catch
| finally
| interface
| static
| while
|
class
| for
| new
| super
| |
continue
| goto
| package
| switch
|
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 A.3.1.)
Most of the classes in the java.lang package are not supported in Java Card. The following classes from java.lang are supported on the card in a limited form.
Java Card 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.
This section describes the optional features of the Java Card platform. An optional feature is not required to be supported in a Java Card 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 types 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 produce 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.
The limitations of resource-constrained hardware prevent Java Card programs 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. Applets that do not violate these maximum values can be converted into 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 class can implement at most 15 interfaces, including interfaces implemented by superclasses.
An interface can inherit from at most 15 superinterfaces.
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.
The maximum number of local variables that can be used in a method is 255, where 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 bytecodes may differ from the number of Java bytecodes in the Java virtual machine implementation of that method.
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 A.4.3).
There is limited support for initialization of static field values in <clinit> methods. Static fields of applets may only be initialized to primitive compile-time constant values, or arrays of primitive compile-time constants. Static fields of user libraries may only be initialized to primitive compile-time constant values. Primitive constant data types include boolean, byte, short, and int.
[1] The Java Card Virtual Machine Specification can be downloaded from the Web site at http://java.sun.com/products/javacard.