Java Cards
Java Cards are the next step in Smart Card technology. Basically, a Java Card is a smart card that can be programmed in a high level language instead of assembly language. This naturally makes producing application software much easier. The choice of Java has other advantages: portability, its popularity in the computing community and its design around applets -- small code objects designed to be downloaded onto a client machine from a remote host -- perfect for smart cards!
A year after the first Java Card specification was released in November 1996, every major vendor of smart cards in the world had licensed the technology. Both Schlumberger and GemPlus, companies that combined sell something like 75 percent of all smart cards, already have implementations and development toolkits for sale. By 2001, over 700 million of the 3 billion cards sold will be Java Cards.
Implementing a fully functional Java system on a card with, say, 1K of RAM, 16K of EEPROM, and 24K of ROM, is probably impossible. However, it is possible to fit in a partial version and this is what we now describe. It has two main parts:
Java Card Virtual Machine (JVM). This defines a logical machine that programmers can easily deal with.
Java Card Runtime Environment (JCRE). This is essentially the card's operating system.
The Java Card Virtual Machine
Programming language
For efficiency reasons, the JVCM only permits a subset of the Java language to be used for programming applets. A brief description of this subset is as follows:
| Supported Java Features | Unsupported Java Features |
| boolean , byte , short, int | double, float, long, character, string |
| One-dimensional arrays | Multi-dimensional arrays |
| Java classes, packages, interfaces, exceptions | Dynamic Class Loading |
| Java object-oriented features: inheritance, virtual methods, overloading and dynamic object creation, access scope, and binding rules | Security Manager |
| Garbage Collection | |
| Threads |
Split structure
The Java Card Virtual Machine is split into two parts: a converter that runs off-card and an interpreter that runs on-card.
On being given a class file and any required export files produced by a third-party Java compiler, the converter does the following:
checks for Java Card language subset violations
resolves symbolic references into a more compact form that can be handled more efficiently on the card
optimizes byte code by taking advantage of information obtained at class loading and linking time
allocates storage and creates virtual machine data structures to represent classes
produces an executable binary CAP file that can run on the interpreter, and an export file.
CAP stands for 'converted applet' and is a new type of file format specially designed for Java Cards. It is loaded onto the card. The export file however, is not. Export files can be thought of as the header files in C; they contain public API information for an entire package of classes. They are used by the converted itself for verification and linking purposes, and can also be distributed by applet developers to users (since they contain no implementation details).
The CAP file is loaded onto the card via a pair of installers on and off the chip. The on-chip installer writes it into the smart card memory, links it with the other classes that have already been placed on the card, and creates and initializes any data structures that are used internally by the Java Card runtime environment.
The division of functionality between the interpreter and the CAP file installer keeps the interpreter small and provides flexibility for installer implementations.
Once it has received a CAP file, the interpreter is responsible for
Executing the byte code (in this sense its name is something of a misnomer)
Controlling memory allocation and object creation
Ensuring runtime security
Java Card Runtime Environment
The installer and the interpreter are not the only system components running on the Java Card. There are others, and together they form the JCRE.
The JVCM handles memory allocation, bytecode execution, object management and security. The native methods handle low-level communication protocols, memory management, cryptographic support and more. The System classes handle the tasks that an operating system core normally would, and invoke the native methods to do this. The API classes are compact 'libraries' that make it easier to create applets. The installer loads applets onto cards. Other extensions are industry-specific libraries; for example the Open Platform extends the JCRE services to meet banks' special security needs.
The JCRE is loaded onto the Java Card at the factory and remains there till the card is destroyed. When the card is placed in a Card Accepting Device (CAD), it is activated and begins copying data/programs from EEPROM and ROM to the faster RAM. During transactions, data and objects that must be preserved are copied from RAM into EEPROM. Recall that EEPROM preserves data in the absence of power. When power is lost, the card goes into hibernation.