Goals, Requirements, and Scope

The goal of the Virtual Machine Specification, Java Card Platform, v3.0.1, Connected Edition is to standardize a highly portable, minimum-footprint Java application-development platform for resource-constrained, smart card and secure token devices.

The devices targeted by the Virtual Machine Specification, Java Card Platform, v3.0.1, Connected Edition have the following general characteristics:

Smart cards, secure tokens and secure portable storage devices are some, but not all, of the devices that might be supported by this specification.

More specifically, the Virtual Machine Specification, Java Card Platform, v3.0.1, Connected Edition defines a Java technology application-development platform with the following characteristics and goals:

Smart card devices are manufactured and deployed in very large quantities (hundreds of thousands, millions, or even tens of millions of units per year). To meet the needs of the cost-conscious card issuer and smart card manufacturers, the Virtual Machine Specification, Java Card Platform, v3.0.1, Connected Edition defines a “lowest common denominator” standard that includes only the minimal Java platform features and APIs for a wide range of smart card vertical market segments.

The Java Card platform is intended to be primarily an application development platform, rather than a systems programming environment. This has certain implications for the Java platform features and APIs to be included in this specification. First, the Virtual Machine Specification, Java Card Platform, v3.0.1, Connected Edition shall include only high-level libraries that provide sufficient programming power for the application developer. Second, we emphasize the importance of generality and portability. The Virtual Machine Specification, Java Card Platform, v3.0.1, Connected Edition shall not provide any APIs that are specific to a certain device category, vertical market or system functionality.

Unlike the past (when smart card devices usually came with a feature set that was hard-coded at the factory), smart card manufacturers are increasingly looking for solutions that allow them to build extensible products that support the dynamic downloading of interactive content from content providers and third party developers. One of the key goals of the Virtual Machine Specification, Java Card Platform, v3.0.1, Connected Edition is to define an environment that is well-suited for the dynamic, secure downloading of applications written in the Java programming language (Java applications) over different kinds of networks to these Java Card technology enabled devices.

The focus on dynamically delivered Java applications means that this specification is intended not only for hardware manufacturers and their system programmers, but also for third party application developers. In fact, we assume that once these Java Card technology enabled smart cards become more accessible to mainstream Java programmers, the vast majority of application developers for Java Card devices will be third party developers rather than smart card manufacturers themselves.

2.2 Requirements

2.2.1 Hardware Requirements

The Java Card platform is intended to run on a wide variety of smart card and secure token devices. The underlying hardware capabilities of these devices vary considerably and, therefore, the Virtual Machine Specification, Java Card Platform, v3.0.1, Connected Edition does not impose any specific hardware requirements other than memory requirements. Even for memory limits, the Virtual Machine Specification, Java Card Platform, v3.0.1, Connected Edition defines only minimum limits for the Virtual Machine and the core platform library classes (java.*, javax.*).

The Virtual Machine Specification, Java Card Platform, v3.0.1, Connected Edition assumes that:

Typical Java Card platform target devices may require significantly more memory than the minimum to support the application containers, Java Card platform framework layers and industry specific extension libraries. Java Card platform smart card devices typically have as much as 512 kilobytes of non-volatile ^[1] read-only memory, 128 kilobytes of non-volatile read-write memory and 24 kilobytes of volatile ^[2] memory.

The ratio of volatile to non-volatile memory in the total memory budget can vary considerably depending on the target device and the role of the Java platform in the device. If the Java platform is used strictly for running system applications that are built in a device, then applications can be prelinked and preloaded, and a very limited amount of volatile memory is needed. If the Java platform is used for running dynamically downloaded content, then devices will need a higher ratio of volatile memory.

Smart card devices are not battery powered and have a wide range of variance with respect to timer and real time clock capabilities. The Virtual Machine Specification, Java Card Platform, v3.0.1, Connected Edition assumes that the platform may only be able to support a low precision interval timer. In addition, upon power up, the platform is able to service requests for the current wall clock time only when re-synchronized with an external time source.

2.2.2 Software Requirements

Like the hardware capabilities, the system software in Java Card platform target devices varies considerably. For instance, some of the devices may have a full-featured operating system that supports multiple, concurrent operating system processes and a hierarchical file system. Many other devices may have extremely limited system software without a notion of a file system. Faced with such variety, the Java Card platform makes minimal assumptions about the underlying system software.

Generally, the Virtual Machine Specification, Java Card Platform, v3.0.1, Connected Edition assumes that a minimal host operating system or kernel is available to manage the underlying hardware. This host operating system must provide at least one schedulable entity to run the Java virtual machine. The host operating system does not need to support separate address spaces or processes, nor does it have to make any guarantees about the real-time scheduling or latency behavior.

2.2.3 Java Card Requirements

A Java Card platform configuration specification shall generally define a subset of the Java technology features and libraries provided by the Java Platform, Standard Edition (Java SE platform). Consequently, rather than providing a complete description of all the supported features, the Virtual Machine Specification, Java Card Platform, v3.0.1, Connected Edition shall only define the variances and differences compared to the full Java Language Specification (JLS) and Java™ Virtual Machine Specification (JVMS). If something is not explicitly specified in the Virtual Machine Specification, Java Card Platform, v3.0.1, Connected Edition, then it is assumed that a virtual machine conforming to the Virtual Machine Specification, Java Card Platform, v3.0.1, Connected Edition MUST comply with the JLS and JVMS.

Note that the absence of optional features in the Java Card platform does not preclude the use of various implementation-level optimizations. For instance, at the implementation level, alternative bytecode execution techniques (such as Just-In-Time compilation) or class representation techniques can be used as long as the observable user-level semantics of the implementation remain the same as defined by the Virtual Machine Specification, Java Card Platform, v3.0.1, Connected Edition.

2.3 Scope

The Virtual Machine Specification, Java Card Platform, v3.0.1, Connected Edition shall address the following areas:

This Virtual Machine Specification, Java Card Platform, v3.0.1, Connected Edition shall not address the following areas:

These features on the Java Card platform are addressed by the Runtime Environment Specification, Java Card Platform, Version 3.0.1, Connected Edition and the Java Servlet Specification, Java Card Platform, Version 3.0.1, Connected Edition.

The remainder of this specification is organized in the following sequence. The specification starts with a discussion of the high-level architecture of a typical Java Card platform environment. Then, the specification compares the Java language and virtual machine features of a virtual machine conforming to the Java Card platform to a conventional Java environment meeting the full Java Language Specification and Java™ Virtual Machine Specification. Finally, the specification describes the Java libraries included in the Java Card platform.

^{1 (Footnote) The term non-volatile is used to indicate that the memory is expected to retain its contents between the user turning the device “on” or “off”. For the purposes of the Virtual Machine Specification, Java Card Platform, v3.0.1, Connected Edition, it is assumed that non-volatile memory is usually accessed in read mode, and that special setup may be required to write to it. Examples of non-volatile memory include ROM, Flash and battery-packed SDRAM. The Virtual Machine Specification, Java Card Platform, v3.0.1, Connected Edition does not define which memory technology a device must have, nor does it define the behavior of such memory in a power-loss scenario.}

^{2 (Footnote) The term volatile is used to indicate that the memory is not expected to retain its contents between the user turning the device “on” or “off”. For the purposes of the Virtual Machine Specification, Java Card Platform, v3.0.1, Connected Edition, it is assumed that volatile memory can be read and written to directly without any special setup. The most common type of volatile memory is DRAM.}

2.1 Goals

2.2 Requirements

2.2.1 Hardware Requirements

2.2.2 Software Requirements

2.2.3 Java Card Requirements

2.3 Scope