java card基础知识

第 2部分 JAVA 卡技术

第 3章 Java卡技术概述

Java卡技术能够使利用 Java 编程语言写的程序在智能卡上和其它资源有限的设备上运行。

本章将对 Java 卡技术－系统体系结构及其组成部分作一概括描述。

3.1 体系结构概述

智能卡代表现今使用的最小的计算平台。智能卡的存储器配置例如可以是：1K RAM, 16K

EEPROM, 和 24K ROM。Java 卡技术设计的最大挑战是：要把 Java 系统软件放到智能卡上，

同时还要为应用保留足够的空间。解决这个问题的办法是只支持 Java 语言特性的子集和采用分

离模式的 Java 虚拟机。

Java 卡虚拟机被分割成两个部分：一部分运行于卡外，而另一部分运行于卡上。许多不限于

运行时执行的处理任务，例如类的 loading，字节码验证，地址确定与链接，以及优化等，由于运

行于卡外的虚拟机来处理，在那里资源通常不必关心。

智能卡在许多方面不同于台式计算机。除了支持Java语言外，Java 卡技术还定义了一个运行

时环境，这个环境支持智能卡存储器、通信、安全，和应用执行模式。Java 卡运行时环境符合智

能卡国际标准 ISO 7816。

Java卡运行环境的最重要的特性就是把智能卡操作系统和应用清晰地分离开来。运行环境将

底层的复杂性和智能卡系统的细节封装起来。应用通过清晰定义的高级编程接口请求系统服务和

资源。

因此，Java 卡技术实质上乃定义了这样一个平台：在这个平台上，用Java编程语言写的应用

能够在智能卡中和其它资源有限的设备上运行。(为 Java 卡平台写的应用称为 applets.)。因为分

离的虚拟机体系结构，该平台从时空角度，乃分布于智能卡和台式机之间。Java 卡技术由三个部

分组成，各于一个规范中定义。

z Java 卡 2.1 虚拟机 (JCVM) 规范：定义 Java 程序设计语言子集和适合于智能卡应用

的虚拟机定义。

z Java 卡运行时环境(JCRE)规范：精确地描述了Java 卡的运行时行为, 包括存储管理、

applet管理，和其它运行时特性。

z Java 卡 2.1 应用编程接口(API) 规范：描述了编程 Java 卡应用的核心与扩展 Java 包

和类。

3.2 Java 卡语言子集

因为它的存储空间之小，Java 卡平台只能支持Java语言特性的一个经过精心挑选的、定制的

子集。 这个子集包括的特性非常适合为智能卡和其它小型设备编写的程序，而却保持了 Java 编

程语言的面向对象的能力。表3.1 着重给出了某些重要的支持的和不支持的 Java 语言特性。

把那些不支持的特性的 keywords 也省略了，这是不足为怪的。许多高级的 Java 卡提供垃

圾收集机制，使对象删除成为可能。

附录 A 提供了 Java 卡语言子集的详尽注释。关于需要存储和操作大数的 Java 卡 applets，

14章提供了在不使用大的基本数据类型的前提下处理大数的编程提示。

表 3.1 支持的和不止持的Java 特性

Supported Java Features Unsupported Java Features

? 小的基本数据类型: boolean,byte, short

?一维数组

?Java包, 类,接口, 和例外

? Java 面向对象的特性:继承,虚拟机,重载和

动态数据对象建立,访问域,以及约束规则

? int keyword 和32-位bit 整数数据类型支持

是任选的。

? 大的基本数据类型: long,double, float

? 字符和字符串

? 多维数组

? 动态类装载

?安全管理器

? 垃圾收集和 finalization

? 线程

? 对象串行化

?对象cloning

3.3 Java 卡虚拟机

Java 卡虚拟机(JCVM) 和Java虚拟机(JVM)之间的一个主要差别在于JCVM 是作为两个分立

的部分实现的，如图3.1所示。Java 卡虚拟机的卡上部分包括 Java 卡字节码解释器。而 Java 卡

转换器运行于PC或工作站。转换器是虚拟机的卡外部分。卡上和卡外部分一起实现了虚拟机的全

部功能，包



图 3.1 Java 卡虚拟机

括 loading Java 类文件和按特定的语意执行之。转换器装载与预处理构成 Java 包的类文件和输

出 CAP (converted applet) 文件。而后将 CAP 文件装载到 Java 智能卡中并有解释器执行。除了

建立 CAP 文件之外，转换器还生成一个表示正北转换的包的公共 APIs 的输出文件。

Java 卡技术只支持Java 语言的子集。相应地，Java 卡虚拟机也只支持那些由该语言子集需

要的特性。转换器将删除那些在 applet 中使用的不支持的语言特性。

3.3.1 CAP 文件和 Export 文件

Java 卡技术引入两种新的二进制文件格式，它们使 Java 卡软件平台无关地进行开发、发布

和执行。一个 CAP文件包含一个Java包中的类的可执行的二进制表示。JAR 文件格式用作 CAP

文件的 container 格式。一个 CAP 文件对应一个包含其诸成分集合的 JAR 文件，每个成分为该

JAR 文件中的一个文件。每个成分描述CAP文件内容的一个方面，例如类信息、可执行的字节码、

链接信息、验证信息，等等。CAP 文件的格式是针对小型化的设备，利用紧缩的数据结构和有限

的间接而被优化了。它定义了一个字节码指令集，该指令集基于 Java 字节码指令集，并对其进

行了优化。

Java 程序的 “写一次，到处运行” 的品性或许是 Jav 平台的最重要特性。在 Java 技术中，

类文件是 Java 体系结构的中心部分，它定义了 java 平台二进制兼容性的标准。因为 Java 卡系

统体系结构的分布式特点，CAP 文件建立了关于 Java 卡平台的二进制兼容性的标准文件格式。

CAP 文件格式就是把软件装载到 java 卡上的形式。例如，CAP 文件能够在卡片做好之后，动

态地装载 applet 类。 这就是其得名 CAP (converted apple) 文件的原因所在。

Export 文件不被装载到智能卡上并且不被解释器直接使用，而它们是由转换器产生并用于验

证和链接过程。可将 Export 文件视为C编程语言中的头文件。一个 export 文件包含一个包的公

共的 API。它定义类的访问域（scope）与名字和方法的访问域与签名，以及类的域（fields）。

一个 export 文件还包含用于卡上包间的 resolving 的链接信息。

export 文件不包含任何关于实现的信息，即不含字节码。所以，一个 export 文件可由applet

开发者自由发布给该 applet 的潜在用户，而不会泄露内部实现细节。

3.3.2 Java 卡 转换器（Converter）

不像 Java 虚拟机（一次处理一个类），转换器的转换单位是一个包。编译器由源代码产生

类文件，而后转换器预处理构成一个 java 包的全部类文件，并将这个包转换为一个 CAP 文件。

在转换过程中，转换器执行桌面环境下Java虚拟机在装载类时所完成的任务：

z 验证Java类的装载映像格式无误

z 检查Java卡语言子集是否违例

z 完成静态变量的初始化

z 将对类、方法和域的符号引用解析为可在卡上有效处理的更紧凑的形式

z 利用在类装载与链接时获得的信息优化字节码

z 分配存储空间和建立表示类的虚拟机数据结构

转换器不仅把类文件作为转换的输入，输入还可能包括一或多个 export 文件。除了产生一

个 CAP 文件外，转换器还产生一个关于被转换包的 export 文件。图 3.2 表明一个包是如何被

转换的。转换器装载一个Java包中的全部类。如果该包输入来自其它包的类，转换器还将装载这

些包的 export 文件。转换器的输出是一个CAP 文件和一个正被转换的包的 export 文件。



图 3.2 转换一个包

3.3.3 Java 卡 解释器（Interpreter）

Java 卡解释器提供 Java 语言模型的运行时支持，因此允许 applet 代码与硬件无关。解释器

执行下列任务：

z 执行字节码指令并最终执行 applets

z 控制存储分配和对象建立

z 在保证运行时安全中扮演重要角色

至此，Java 卡虚拟机已经被描述为由转换器和解释器组成。然而，在我们目前的定义中非正

式地把 Java 卡虚拟机被定义为该虚拟机的卡上部分――解释器。这一习惯已经用于许多早期的

Java卡出版物中。因此，本书后面的部分将会同时使用“Java 卡解释器”和“Java 卡虚拟机”这

两个词，除非另外说明。但是，在比较 Java 卡平台和 Java 平台时，读者应知道执行 Java 类文

件的功能是由转换器和解释器二者一起完成的。

3.4 Java 卡 Installer 和卡外安装程序

Java 卡解释器本身并不装载 CAP 文件，它只执行在 CAP 文件中发现的代码。在 Java 卡

技术中，下载和安装 CAP 文件的机制乃包含在一个称为安装器（installer）的部件中。

Java 卡安装器驻留在卡片中，它与卡外的一个安装程序协同工作。该卡外安装程序通过卡片

接收设备(CAD)，将CAP文件中的可执行的二进制代码传送给在卡上运行的安装器。安装器把二

进制代码写入智能卡存储器中，将其与已经放在卡片上的其它类进行链接，并建立和初始化由Java

卡运行时环境内部使用的任何数据结构。安装器和安装程序以及它们如何与 Java 卡平台的其余

部分相关联示于图3.3。

解释器和CAP文件安装器间功能的拆分使得解释器保持较小，并且提供安装器实现的灵活性。

关于安装器的更多的解释在本章后头的 applet 安装中给出。

PC或工作站



图 3.3 Java 卡安装器和卡外安装程序

3.5 Java 卡运行时环境

Java 卡运行时环境(JCRE) 由运行于智能卡中的一些 Java 卡系统组件构成。 JCRE 负责卡

片资源管理、网络通信、applet 执行，和卡上系统与 applet 的安全。因此，它实际上充当智能卡

操作系统的角色。

如图3.4所示，JCRE 位于智能卡硬件和 native 系统的顶上。JCRE 由 Java 卡虚拟机(字节码

解释器)、Java 卡应用架构类(APIs)、业界专用扩展，以及一些 JCRE 系统类组成。JCRE 很好地

将 applets 和智能卡厂商的专用技术隔离开来，并为 applets 提供标准的系统和API 接口。因此，

applets 很容易写和在各种不同的智能卡体系结构上移植。

JCRE 的底层包含Java 卡虚拟机(JCVM)和一些 native 方法。 JCVM 执行字节码、控制存

储器分配、管理对象，和保证执行的安全性，如前所述。native 方法提供对 JCVM 和上层系统

类的支持。它们负责处理低级通信协议、存储管理、cryptographic 支持等。

Applets

JCRE

智能卡硬件和Native 系统

优惠应用 钱包应用 认证应用

业界专用扩展 安装程序 架构类（APIs）

Applet 管理 事物管理 I/O网络通信 其它服务

Java 卡虚拟机

（字节码解释程序）

Native 方法



图 3.4 卡上系统的体系结构

系统类作为 JCRE 执行程序。这些类是对操作系统核心的模拟。系统类负责管理事物、管理

host 应用1

和 Java 卡 applets 之间的通信，以及控制 applet 的建立、选择，和 deselection。为

了完成这些任务，系统类一般地要调用 native 方法。

Java 卡应用架构定义了应用编程接口。这个架构由四个核心 API 包和一个扩展 API 包组

成。这些 API 类是很紧凑的，并且是专门为开发智能卡 applets 而定制的。 该架构的主要优点

在于使得一个 applet 的建立变得容易了。于是，applet 开发者的主要精力可其集中在其 applet

的细节上，而不是智能卡系统基础设施的细节上。Applets 通过API 类访问 JCRE 的服务。

各行业可以提供扩充库，以提供附加的服务或改善安全和系统模型。例如，Open Platform 扩

展了JCRE 的服务，以满足金融界专门的安全要求。在许多追加的特性中，强制了发卡行对卡片

的控制并规定了卡片个人化的标准命令集。

卡上安装程序能够保证在卡片生产完毕并发行给持卡人之后，软件和 applets 能够安全地下

载到卡片中。卡上安装程序和卡外安装程序协同操作，它们共同完成 CAP 文件的二进制内容的

下载任务。卡上安装程序是一个任选的 JCRE 组成部分。在没有卡上安装程序的时候，所有的卡

片软件（包括applets）都必须在卡片制造过程中写到卡片的存储器中。

Java 卡 applets 是 Java卡平台上的用户程序。当然，applets 是利用 Java 编程语言的的子集

编写的，并由 JCRE 进行控制和管理。Applets 可在 Java 智能卡制造好之后再加载到卡上。

3.5.1 JCRE 生命周期

在PC或工作站中，Java 虚拟机是作为一个操作系统进程运行的。数据和对象被建立于 RAM

之中。当该 OS 进程被终止的时候，Java 应用及其对象被自动地废弃。

在Java 智能卡中，Java 卡虚拟机在Java卡运行时环境中运行。JCRE 于卡片初始化时被初始

化。在整个卡片生命期中，JCRE 仅被初始化一次。在这个过程中，JCRE 初始化虚拟机并建立

提供 JCRE 服务和管理 applets 的对象。在安装 applers 的时候，JCRE 建立 applet 实例，而

applets 建立存储数据的对象。

智能卡上的大多数信息即使在卡片断电的时候都必须被保留下来。我们可利用永久存储器技

术（例如EEPROM）来实现这一保持数据的目的。数据和对象被建立于永久存储器中。JCRE 的

生命期相当于整个卡片的生命期。当去电的时候，虚拟机只是被挂起。JCRE 和在卡片上建立的

对象的状态则被保留下来。

下次卡片上电的时候，JCRE 通过从永久存储器2

装载数据而重新启动虚拟机执行。这里一

个微妙的概念是 JCRE 并非恰好从掉电时的断点来继续虚拟机的操作。而是虚拟机被复位，并从

主循环的开头执行。JCRE 复位与初始化不同，因为它要保留在卡片上建立的 applets 和对象。

在复位期间，如果某个事物在之前未完成，JCRE 将进行任何必要的清楚工作，使JCRE 呈一致

的状态。

3.5.2 在一个 CAD Session 中 JCRE如何工作?

从卡片插入卡片接受设备(CAD)并加电至卡片从 CAD 拔出的时间段称为一个 CAD 会话期

（session）。在 CAD 会话期中，JCRE 像普通智能卡一样地操作—它支持与 host 应用的 APDU

I/O 通信(图 3.5).。APDUs (应用协议数据单位)是在 applets 和 host 应用之间交换的数据包。每

一个 APDU 或者包含从 host 至 applet 的命令或者从 applet 至 host 的响应。

在 JCRE 复位之后，JCRE 便进入一个循环，等待来自 host 的 APDU 命令。 host 通过卡

片的输入/输出触点提供的串行通信接口向 Java 卡平台发送 APDU 命令。



图 3.5 APDU I/O 通信

当一条命令到来的时候，JCRE 或者按照该命令的指示，选择一个 applet ，或者将接收到的

命令继续交给当前已经被选择的 applet。而后，被选择的 applet 取得控制，并处理该 APDU 命

令。

在结束的时候，该 applet 向 host 应用发送响应并把控制交还给JCRE。在下一条命令到来的

时候，又重复这一过程。Applets 如何处理 APDUs 将于第7和第 8 章中予以说明。

3.5.3 Java 卡运行时特性

除了支持 Java 语言的运行时模式之外，JCRE 还支持三种附加的运行时特性：

z 永久和临时对象—按缺省，Java 卡对象是永久的并被建立于永久存储器中。这种对象的

空间与数据跨 CAD 会话期。因为安全性与性能的原因，applets 也可在 RAM 中建立

对象，这样的对象称为临时对象。临时对象包含非永久的，不跨 CAD 会话期的临时数

据。

z 原子操作与事物— Java 卡虚拟机保证每次向一个对象或类中的一个域的写操作是原子

的。被修改的域或者取得新值或者被恢复为原先的值。另外，JCRE 还提关于供事物的

APIs。 Applet 可将若干写操作置于一个事物之中。要么一个事物中的全部修改都被完成，

要么（如果在该事物当中发生错误）什么都不作。

z Applet防火墙与共享机制 — applet 防火墙将各 applets 隔离开来。每个 applet 运行于一

个指定的空间之内。 一个 applet 的存在与操作对卡片上其它 applets 不会有影响。 applet

防火墙在 Java 卡虚拟机执行字节码的时候被强制。在 applets 需要共享数据或访问

JCRE 服务的场合，虚拟机通过安全的共享机制来满足这些功能。

3.6 Java 卡APIs

Java 卡 APIs 是由一些为根据 ISO 7816 模式编程智能卡应用而定制的类组成的。APIs 包

含三个核心包和一个扩展包。三个核心包是：java.lang、javacard.framework，和

javacard.security。扩展包是javacardx.crypto。

熟悉 Java 平台的开发者会注意到许多 Java 平台的类在 Java 卡 APIs 中并不被支持。例

如，Java 平台的关于 GUI 接口、网络 I/O，和 台式机文件系统 I/O 的类并不被支持。其原因

在于智能卡没有显示器，并且它们使用不同的网络协议以及文件系统结构。另外，也不支持许多

Java平台的实用程序类，以满足特定的存储器需求。

在 Java 卡 APIs 中的类是紧凑而简明的。它们包括一些为了提供 Java 语言支持和密码技

术服务而根据 Java 平台改编的类。它们还包括一些为支持智能卡 ISO 7816 标准而专门建立的

类。

3.6.1.java.lang 包

Java 卡的 java.lang 包是其 Java 平台上的对应包 java.langpackage 的严格子集。该包所支

持的类是 Object, Throwable，和某些与机器有关的例外类，如表 3.2 所示。对于所支持的类，

许多 Java 方法是不能用的。例如，Java 卡 Object 类 只定义了缺省的构造方法和 equals 方

法。

java.lang 包提供基本的 Java 语言支持。类 Object 为 Java 卡类层次结构定义了一个根，

而类 Throwable 为所有的例外提供了一个共同的祖先。所支持的例外类保证在由于 Java 语言

违例而导致错误发生时有一致性的语意。例如，当访问一个空引用时，Java 虚拟机和 Java 卡虚

拟机都抛出一个 NullPointerException 例外。

Table 3.2 Java 卡java.lang 包

Object Throwable Exception

RuntimeException ArithmeticException ArrayIndexOutOfBoundsException

ArrayStoreException ClassCastException IndexOutOfBoundsException

NullPointerException SecurityException NegativeArraySizeException

3.6.2.javacard.framework 包

javacard.framework 是一个重要的包。 它为 Java 卡 applet 的核心功能提供了架构类和

接口。最重要的是它定义了一个基础 Applet 类，后者为 applet 的执行和其生命期内与 JCRE 的

交互提供了一个框架。它在面对 JCRE 所扮演的角色方面，类似于 Applet 类面对 host 浏览器

时的角色。一个用户 applet 类必须从基类 Applet 扩展而来，并且重写 Applet 类中的方法以实

现该 applet 的功能。

javacard.framework 包中的另一个重要的类是 APDU 类。APDUs 由传输协议传送。两个

标准的传输协议是 T=0 和 T=1。 APDU 类设计得与传输协议无关。换言之，它是被精心设计

的，从而使 applet 的开发者感觉不到 T=0 和 T=1 协议的复杂性以及它们之间的差异。Applet

开发者可利用 APDU 类中提供的方法极其容易地处理 APDU 命令。不管平台支持的底层传输

协议为何，Applets 都能正确地工作。在第 8 章中将说明如何使用 APDU 类。

Java卡平台不支持 Java 平台的类 java.lang.System 。 Java 卡平台包含一个提供与系统性能

相关的接口类 javacard.framework.JCSystem 。JCSystem 类包括控制 applet 执行、资源管

理、事物管理，以及 Java 卡平台上 applet 间对象共享的方法集。

javacard.framework 包中支持的其它类是 PIN，实用程序，和例外。PIN 是个人标识号

（personal identification number）的简称。它是为了认证持卡人而在智能卡中使用的最普通的口令

形式。

3.6.3.javacard.security 包

javacard.security 包 提供关于Java卡平台上支持的密码功能的架构。它的设计基于包

java.security。

javacard.security 包 定义了一个密钥工厂类 keyBuilder 和描述用于对称(DES)或非对称

(DSA 和 RSA)算法中的密码技术密钥的各种接口。此外，它还支持抽象的基类 RandomData、

Signature,和 MessageDigest，后者用于生成随机数数据和计算报文摘要与签名。

3.6.4.javacardx.crypto 包

javacardx.crypto 包是一个扩展包。它包含受制于美国出口条例要求的密码技术类和接口。

javacardx.crypto 包定义关于支持加密和解密功能的抽象基类 Cipher 。

包 javacard.security 和 javacardx.crypto 定义 applets 调用请求密码技术服务的 API

接口。然而，它们并未提供任何实现。一个 JCRE 提供者需要提供这些密钥接口的类并继承抽

象类 RandomData, Signature, MessageDigest,和 Cipher。通常，卡片上有一个独立的协处理器

来完成密码技术有关计算。第10章将解释如何利用包 javacard.security 和 javacardx.crypto

中的类支持 applets 中的密码技术功能。

3.7 Java 卡Applets

不要就因为 Java 卡 applets 和 Java applets 名字都叫 applet，而将二者相混淆。一个 Java

卡 applet 是一个要遵守一组约束的 Java 程序，只允许它运行于 Java 卡运行时环境中。一个

Java 卡 applet 不会在一个浏览器环境中运行。为 Java 卡应用取名 applet 的原因在于在卡片已

经制造好之后，仍能够将 Java 卡 applets 装载到 Java 卡运行时环境中。即，不像在许多嵌入式

系统中那样，不需要在制造阶段将 applets 烧到ROM中。而是，在以后的某时刻，能将它们动态

地下载到卡片中。

一个 applet 类必须从 javacard.framework.Applet 类扩展而来。基类 Applet 是驻留在

Java卡中的所有 applets 的超类。这个 applet 类是定义一个 applet 中的变量和方法的模板。一个

正在卡片上运行的 applet 是一个 Applet 实例 — 该 applet 类的一个对象。像任何永久对象一

样，一个 applet 实例一旦被建立，它就会永久存活在卡片上。Java 卡运行时环境支持多应用环

境。多个 applets 能够并存于同一张 Java 智能卡上，并且一个 applet 可建有多个实例。例如，

可建立一个钱包 applet 实例支持美元, 而建立另一个实例支持英镑。

3.8 包和Applet 命名约定

你所熟悉的 Java 平台中的包和程序是利用 Unicode 串和基于 Internet 域名的命名方案来

唯一标识的。然而，在 Java 卡平台中，每个 applet 实例是通过应用标识符（AID）来唯一标识

和选择的。另外，每个 Java 包也被赋予一个 AID 。当把包装载到卡片上的时候，便通过它们

的AID将其与卡片上的其它包链接起来。

ISO 7816 规定了用于唯一标识卡片的应用和卡片文件系统中某些类型域的APIs。一个 AID

是一个字节数组，可被解释为两个不同的部分，如图 3.6 所示。第一部分是一个 5 字节的值，

称为 RID (源标识符)。第二部分是一个可变长度的值，称为 PIX (专用标识符扩展)。 PIX 的长

度可从 0 到 11 字节。因此，一个 AID 总长可从 5 到 16 字节。

RID (5 bytes) PIX (0–11 bytes)



图 3.6 应用标识符 (AID)

ISO 控制给公司 的 RIDs 分配；每个公司有一个唯一的 RID。 公司自己管理AIDs中的

PIXs 的分配。本节只对 AIDs 进行简要地描述。关于全部细节，请参见 ISO 7816-5，AID 注册

分类 D 的格式。

在 Java 卡平台中，一个包的 AID 是通过该公司的 RID 和这个包的 PIX 的链接而构成的。

一个 applet 的 AID 是以和包 AID 类似的方法而构造的。它是该 applet 提供者的 RID 和该

applet 的 PIX 的链接。一个 applet 的 AID 一定不要用和任何包的 AID 或任何其它 applets 的

AID 相同的值。然而，由于一个 AID中的 RID 标识 applet 提供者，包 AID 及在该包中定义的

applets 的 AID(s) 必须具有相同的 RID。包 AID 和在该包中定义的每个 applet 的缺省 applet

AID 在 CAP 文件中指出。在生成 CAP 文件时，将它们提供给转换程序。

3.9 Applet 下载过程

Java 卡 applet 的开发和任何其它 Java 程序一样而开始。开发者编写一个或多个 Java 类

并用某 Java 编译器编译源代码，产生一个或多个 class 文件。图 3.7 演示了applet 的开发过程。

接着，在模拟环境中运行、测试，和调试该 applet。模拟器在 PC 或工作站上模拟 Java 卡

运行时环境。在模拟环境中，applet 于 Java 虚拟机上运行，并因此而执行该 applet 的 class 文

件。通过这种方法，模拟器能够利用许多 Java 开发工具(虚拟机、debugger, 和其它工具)并允许

开发者



图 3.7 Applet 的开发过程

测试 applet 的行为和快速观看 applet 的执行结果，而不用经历转换过程。在这一步中， applet 的

整个功能方面得以测试。然而，某些 Java 卡虚拟机运行时特性，例如 applet 防火墙以及对象的

临时与永久行为，则不能被检查。

而后，通过 Java 卡转换程序将构成一个Java包的 applets 的 class 文件被转换为一个 CAP

文件。Java 卡转换程序的输入不仅有被转换的 class 文件，还有一个或多个 export 文件。在转

换该 applet 包的时候，转换程序还为这个包产生一个 export 文件。 一个 CAP 文件或一个 export

文件代表一个 Java 包。如果一个 applet 由若干包组成，那么为每一个包建立一个 CAP 文件和

一个 export 文件。

在下一步中，将代表该 applet 的 CAP 文件（可能不止一个）装载到一个仿真环境中并在该

环境中进行测试。仿真器也在一台 PC 或工作站上模拟 Java 卡运行时环境。然而，仿真器是一

个更为复杂的测试工具。它包含一个 Java 卡虚拟机 的实现。Applet 在仿真器中的执行行为应和

运行于实际卡片中的行为是一样的。在这一开发阶段，不仅 applet 得以进一步测试， 而且该 applet

的运行时行为也得到测试。

大多数 Java 卡模拟器和仿真器都带有调试程序（debugger）。该调试程序允许开发者设置断

点或单步执行程序、观看在该模拟或仿真的 Java 卡运行时环境中的 applet 修改后的执行状态。

最后，当 applet 被测试后并准备好被下载到实际的卡片中的时候，该 applet（由一个或若干

的 CAP 文件代表）便被装载和安装到 Java 智能卡中。

3.10 Applet 安装

在制造 Java 智能卡的时候， 该智能卡的专用系统及其运行时环境（包括本地（native）方

法、Java 卡虚拟机、API 类，以及库）都被烧到 ROM 中。这个将一些固定的成分写到芯片的

不易变的存储器的过程称为掩模（masking）。掩模技术是智能卡厂商的专用工艺技术，本书不再

进一步讨论。

3.10.1 ROM Applets

在卡片制造过程中，Java 卡 applet 类可以和 JCRE 及其它系统成分一起掩模到 ROM 中。

在 JCRE 初始化期间或以后某一时刻，由 JCRE 将 Applet 实例实例化到 EEPROM 中。这样的

一些 applets 称为 ROM applets。

ROM applets 是缺省的 applets ，由卡片发行者提供，随卡一起提交。由于 ROM applet 的

内容由发行商控制，Java 卡 工艺技术允许 ROM applets 声明本地（native）方法，这些方法的

实现是利用别的编程语言（例如 C 或汇编代码）写的。本地方法不受由卡片虚拟机强制的安全

检测。.

3.10.2 事前或事后发行 Applets

另外，在卡片制造之后，Java 卡 applet 的类和相关的类库也能够被下载或写到 Java 智能卡

的可变存储器（例如 EEPROM）中。这样的 applets 可进一步分类为事前发行或事后发行的

applets。事前和事后这两个词是根据 applets 是在卡片发行之前或之后下载的事实而确定的。事

前发行的 applets 按 ROM applets 相同的方式处置，二者都由发卡方控制。

和 ROM applets 或事前发行的 applets 不同，事后发行的 applets 不允许声明本地方法。原

因在于 JCRE 没有办法控制该 applet 的内容。允许被下载的 applets 包含本地代码会有损于

Java 卡的安全性。以下几节将集中于事后发行的 applet 的安装。通常，事前发行的 applets 是

利用和事后发行的applets相同的机制装载的，但是 Java 卡技术把决定权留给卡片发行者。

3.10.3 事后发行的 Applet 的安装

Applet 安装指的是将 applet 类装载到一个 CAP 文件中、将这些类和 Java 卡运行时环境的

执行状态相结合，以及建立一个 applet 实例，从而使该 applet 成为能被选择执行的状态的过程。

在 Java 卡平台上，装载和可安装的单位是一个 CAP 文件。一个 CAP 文件由构成一个 Java

包的类组成。一个最小的 applet 就是一个只具有一个从 javacard.framework.Applet 类继承的类

的包。一个具有很多类的更复杂的 applet 可被组织成一个或一组 Java 包。

为了装载一个 applet，卡外安装程序将 CAP 文件作为输入并将其转换为 APDU 命令序列，

该命令序列携带该 CAP 文件的内容。通过和卡外安装程序交换 APDU 命令，卡上安装程序把

该 CAP 文件的内容写到卡片的永久存储器中，并将该 CAP 文件中的类与驻留在卡片上的其它

类相链接。该安装程序还建立和初始化任何由 JCRE 内部用于支持 applet 的数据。如果该 applet

需要若干包运行，要把每个相应的 CAP 文件都装载到卡片上。

作为 applet 安装的最后一步，安装程序建立一个 applet 实例并将这个实例向 JCRE3

注册。

为了做到这一点，安装程序调用 install 方法：

public static void install(byte[] bArray, short offset, byte length)；

install 方法是一个 applet 入口点方法，类似于一个 Java 应用中的 main 方法。一个 applet 必

须实现 install 方法。在 install 方法中，它调用 applet 的构造方法以建立和初始化 applet 实例。

install 方法的 bArray 参数提供关于 applet 初始化的安装参数。这些安装参数随 CAP 文件一起

发送给卡片。applet 开发者定义安装参数的内容和格式。

在 applet 被初始化并向 JCRE 注册之后， 它便可被选择运行。 JCRE 利用AID （应用标识符）

标识一个正在运行的 applet。applet 可利用在 CAP 文件中找到的缺省 AID，或者另选择一个不

同的 AID 向 JCRE 注册自己。可利用安装参数提供一个另外的 AID。

install 方法可被调用多次，以建立多个 applet 实例。每个 applet 实例都由一个唯一的AID

标识。在 Java 卡环境中，一个 applet 可在不知道如何装入它的类的情况下而编写和执行。在安

装过程中，一个 applet 的唯一责任就是实现 install 方法。

3.10.4.Applet 安装期间的错误恢复

安装过程是事务性的。在发生错误的情况下，例如程序性故障、运行范围超出存储器大小、

卡片拔出，或者其它错误，安装程序都要抛弃该 CAP 文件和在安装过程中它已经建立的任何

applet 并恢复空间和 JCRE 的以前状态。

3.10.5. 安装限制

读者应当知道 applet 安装是不同于运行时动态类装载的，后者是在台式机环境中的 Java虚

拟机上被支持的。Java 卡 applet 安装只意味着在卡片已经制造好之后通过安装过程下载类的过

程。

因此，Java 卡 applet 安装有两个细节。第一，运行于卡片上的 applets 仅指已经存在于卡

片上的类，由于在 applet 代码正常执行期间没有办法下载类。

第二， 装载的次序必须保证： 每个被新装入的包只引用已经在卡上的包。 例如， 对于一个 applet

来说，javacard.framework 包必须在卡片中, 因为所有的 applet 类都必须从类

javacard.framework.Applet 扩展而来。 如果存在包 A 和包 B 循环引用情况， 安装过程将失败。