Java Reference
In-Depth Information
At the end of a CAD session, when the power is removed from the card, the JCRE is only sus-
pended. Thanks to the persistent storage (EEPROM) the whole computation state is preserved.
Only transient objects (created in RAM for security and performance reasons) are permanently
deleted. The next time power is switched on, starting a new CAD session, the JCRE interpreter
will be reset to the beginning of the main loop.
During a CAD session, the card program emerges from hibernation and starts to run. Usually,
its main activity is communicating with the hosting application via the CAD hardware support.
This I/O process is known as
application protocol data units (APDUs)
I/O. APDUs are low-
level data packets exchanged between applets and the host application. APDUs can contain
both data and commands, and are processed by one of the currently installed applets that even-
tually will return an APDU response to the host application.
An important feature offered by the interpreter is the atomicity of operations and transactions.
Simple operations, such as modifying the fields of a class instance, are ensured to be atomic by
the JCRE, (that is, the state after the operation will be either modified to the new value or
restored to the previous one—no inconsistent states are possible). Transactions are supported
via an API that allows developers to encapsulate several operations in one transaction. In case
of failure during the transaction execution, all performed operations are rolled back, which
restores the computation state to just before the transaction started.
The Java Card Virtual Machine (JCVM) differs from the usual JVM because it is separated in
two pieces: one (the interpreter) on the card, and the other (the converter) is implemented as a
software program running on a workstation or PC.
The converter job is to create card executables files from the Java
.class
files. Such exe-
cutable files are called
CAP (converted applet)
files. Together with CAP files, the converter
produces export files, containing descriptions of the CAP file. The export files are similar to C
header files, and are produced only to be used internally by the converter for linking and verifi-
cation purposes.
The converter plays an important role: to transform the class files into a compact, optimized
format suitable for execution on such a limited environment. Furthermore, is responsible to
check for compliance with the Java Card language specification. It would raise an error if, for
example, a long variable would be used in one of the input class files.
The CAP file format (the main output of the converter) is itself JAR-compatible (that is, com-
pliant with the ZIP standard format), but it is optimized for occupying the minimum size, using
compact data structures and limited indirection for the ZIP format. CAP files are conceptually
equivalent to what JAR files are on other Java platforms: a standard means of distributing Java
programs.
