The Java Card platform is the tiniest of Java targeted for embedded devices. It is an open, interoperable platform for smart cards and secure tokens; the technology is also widely used in SIM cards (it's used in GSM mobile phones) and ATM cards.
Java Card gives users the ability to program a device and make it application specific and lets smart card developers use a common card platform. Smart cards, unlike magnetic stripe cards, can carry all necessary functions and information on the card; therefore, they do not require access to remote databases at the time of the transaction.
The latest version of the Java Card is 2.2.2; it is ready for the next generation of smart card standards, and it's fully backward compatible with previous versions. Key benefits of Java Card 2.2.2 include: improved interoperability for cards with multiple communication interfaces; richer cryptography and security features; and standardized biometry support. It also provides a series of new APIs for a more memory efficient application development.
Applets
Java Card products are based on the Java Card platform specifications developed by Sun Microsystems. Applications written for the Java Card platform are named applets, just like Web applications. The term applet was chosen because of similarities in execution model with the standard Web-based applets.
Java Card aims to define a standard smart card computing environment, allowing the same Java Card applet to run on different smart cards (much like how a Java applet runs on different computers). As in Java, this is accomplished using the combination of a virtual machine (the Java Card Virtual Machine) and a well-defined runtime library, which largely abstracts the applet from differences between smart cards.
Portability and security
The main features of the Java Card technology are portability and security. Portability remains mitigated by issues of memory size, performance, and runtime support (e.g., for communication protocols or cryptographic algorithms).
Java Card technology was originally developed for the purpose of securing sensitive information stored on smart cards. Security is determined by various aspects of this technology, which include the following:
Applet: The applet is a state machine that processes only incoming command requests and responds by sending data or response status words backs to the interface device.
Cryptography: Commonly used encryption algorithms like DES, 3DES, AES, and RSA are supported. Cryptographic services like signing, key generation, and key exchange are also supported.
Applet firewall: Different applications are separated by an applet firewall that restricts and checks access of data elements of one applet to another.
Data encapsulation: Data is stored within the application. Java Card applications are executed in an isolated environment (the Java Card Virtual Machine), separate from the underlying operating system and hardware.
Differences in Java language
Due to strict hardware limitations, Java Card can support only a certain subset of Java languages. All language constructs of Java Card exist in Java and behave identically. As part of a standard build cycle, a Java Card program is compiled into a Java class file by a Java compiler without any special option (the class file is post-processed by tools specific to the Java Card platform).
Many Java language features are not supported by Java Card, such as types char, double, float, and long; the transient qualifier; enums; arrays of more than one dimension; finalization; object cloning; and threads. Also, some features are a runtime option missing in many actual smart cards; in particular, type int, which is the default type of a Java expression, and garbage collection of objects.
Java Card bytecode run by the Java Card Virtual Machine is a functional subset of J2SE bytecode run by a Java Virtual Machine, but it uses a different encoding optimized for size. A Java Card applet typically uses less bytecode than the hypothetical Java applet obtained by compiling the same Java source code. This conserves memory, which is a necessity in resource constrained devices like smart cards. As a design tradeoff, there is no support for some Java language features (as mentioned above), and there are size limitations. Techniques exist for overcoming the size limitations, such as dividing the application's code into packages below the 64 KB limit.
Standard Java Card class library and runtime support differs at lot from that in Java, and the common subset is minimal. For example, the Java Security Manager class is not supported in Java Card; the Java Card Virtual Machine implements security policies. Transients (non-persistent, fast RAM variables that can be class members) are supported via a Java Card class library; they have native language support in Java.
Coding techniques used in a practical Java Card program differ significantly from what is used in a Java program. Java Card uses a precise subset of the Java language; this speeds up the learning curve and enables using a Java environment to develop and debug a Java Card program. Even if debugging occurs with Java bytecode, you should make sure that the class file fits the limitation of Java Card language by converting it to Java Card bytecode. Also, test in a real Java Card smart card early on to get an idea of the performance.