Binary Representation
数据格式
This chapter presents information about the binary representation of Java Card
programs. Java Card technology-based binaries (“Java Card binaries”) are usually
contained in files, therefore this chapter addresses binary representation in terms of
this common case.
这章提供了java卡程序的数据格式信息。java卡数据结构通常被包含在文件中。因此这章描述了文件的一些通常的操作。
Several topics relating to binary representation are covered. The first section
describes the basic organization of program representation in export and CAP files,
as well as the use of the Java? Archive (JAR) file containers. The second section
covers how Java Card applets and packages are named using unique identifiers. The
third section presents the scheme used for naming and linking items within Java
Card API packages. The fourth and fifth sections describe the constraints for upward
compatibility between different versions of a Java Card technology-based binary
(“Java Card binary”) program file, and versions assigned based upon that
compatibility.
关于数据结构的若干个话题会被涉及，第一章描述了类似于java JAR文件的EXP和CAP文件的基本组织结构。第二章涉及到java卡应用和包使用唯一标志命名的方法。第三章描述了用于java卡API中命名和链接的方案。
第四和第五章描述了java卡数据结构为了兼容性所做的限制，以及在此之上的版本控制。
4.1 Java Card Platform File Formats
4.1 java卡平台文件格式
Java programs are represented in compiled, binary form as class files. Java class files
are used not only to execute programs on a Java virtual machine, but also to provide
type and name information to a Java compiler. In the latter role, a class file is
essentially used to document the API of its class to client code. That client code is
compiled into its own class file, including symbolic references used to dynamically
link to the API class at runtime.
Java Card technology uses a different strategy for binary representation of
programs. Executable binaries and interface binaries are represented in two separate
files. These files are respectively called CAP files (for converted applet) and export
files.
java程序在编译后用类文件的数据格式来承载。java类文件不仅仅用来在java虚拟机上执行程序，也用来为java编译器提供类型和命名信息。在后一个职责中，类文件本质上是被用来作为其使用者的API文档。
使用者代码被编译成包含了用于动态链接到API类符号索引的子集的类文件。
java卡技术使用一个数据结构上不同的策略。执行数据和接口数据在两个不同的文件提供。这俩文件也相应的叫做CAP文件和export文件。
4.1.1 Export File Format
4.1.1 导出文件格式
Export files are not used directly on a device that implements a Java Card virtual
machine. However, the information in an export file is critical to the operation of the
virtual machine on a device. An export file can be produced by a Java Card
converter when a package is converted. This package’s export file can be used later
to convert another package that imports classes from the first package. Information
in the export file is included in the CAP file of the second package, then is used on
the device to link the contents of the second package to items imported from the first
package.
导出文件不被java卡虚拟机直接使用。然而导出文件的信息是对运行在设备上的虚拟机操作由决定性意义的。导出文件是在java卡converter在转化包的时候生成的。
这个包的导出文件可以稍后被用来转化使用了这个包的类的另外一个包。export文件中的信息将被第二个包的CAP所包含，然后被设备用来链接第二个包和第一个包导出的对象。
A Java Card technology-based export file (“Java Card export file”) contains the
public interface information for an entire package of classes. This means that an
export file only contains information about the public API of a package, and does
not include information used to link classes within a package.
The name of an export file is the last portion of the package specification followed
by the extension ‘.exp’. For example, the name of the export file of the
javacard.framework package must be framework.exp. Operating systems that
impose limitations on file name lengths may transform an export file’s name
according to their own conventions.
For a complete description of the Java Card export file format, see Chapter 5, “The
Export File Format”.
java卡export文件包含包中所有类的公有接口。这意味着导出文件只包含一个包的公有接口，并不包含用以在包内部访问的package可见的接口。export文件类型是.exp。举例，javacard.framework包的export文件名一定是framework.exp。
对文件名有长度限制的操作系统可能根据其不同的规则转化export文件的名字。
更完整的描述参阅第五章。
4.1.2 CAP File Format
4.1.2 CAP文件结构
A Java Card CAP file contains a binary representation of a package of classes that
can be installed on a device and used to execute the package’s classes on a Java Card
virtual machine.
A CAP file is produced by a Java Card converter when a package of classes is
converted. A CAP file consists of a set of components, each of which describes a
different aspect of the contents. The set of components in a CAP file can vary,
depending on whether the file contains a library or applet definition(s).
For a complete description of the Java Card CAP file format, see Chapter 6, “The
CAP File Format”.
java卡CAP文件包含了可以被安装到设备并可以在java卡虚拟机上执行包中类的数据结构。
CAP文件是java卡converter在转化包的时候生成的。一个CAP文件由一组组件组成，每个组件描述了数据的一个分支。对库包（不提供applet）和应用包（提供一个或者多个applet），CAP文件有不同的结构。
更完整的描述参阅第六章
4.1.3 JAR File Container
4.1.3 JAR文件容器
The JAR file format is used as the container format for CAP files. What this
specification calls a “CAP file” is just a JAR file that contains the required set of CAP
components (see Chapter 6, “The CAP File Format”).
JAR文件格式被用来作为CAP文件的容器。这个规范中的CAP文件其实就是一个包含了若干组CAP组件的JAR文件。
CAP file components are stored as files in a JAR file. Each CAP file component is
located in a subdirectory called javacard that is in a directory representing the
package. For example, the CAP file components of the package com.sun.framework
are located in the directory com/sun/framework/javacard.
An export file may also be contained in a JAR file, whether that JAR file contains
CAP file components or not. If an export file is included, it must be located in the
same directory as the components for that package would be.
The name of a JAR file containing CAP file components is not defined as part of this
specification. Other files, including CAP file components for another package, may
also reside in a JAR file that contains CAP file components.
CAP文件组件被存储在一个JAR文件中，所有的CAP文件组件都存放于一个包目录下的javacard的子目录中。举个例子，包com.sun.framework的CAP组件存放于目录com/sun/framework/javacard.
不管JAR文件中是否包含CAP组件，EXP文件也可以被包含到JAR结构中。如果包含EXP文件，则必须放在对应CAP组件相同的目录中。
包含了CAP组件的JAR文件命名在这章没有定义。其它的文件，包括其它包的CAP组件也可以同时存在一个包含了CAP组件的JAR文件中。
4.2 AID-based Naming
4.2 AID基础的命名
This section describes the mechanism used for naming applets and packages in Java
Card CAP files and export files, and custom components in Java Card CAP files.
Java class files use Unicode strings to name Java packages. As the Java Card
platform does not include support for strings, an alternative mechanism for naming
is provided.
ISO 7816 is a multipart standard that describes a broad range of technology for
building smart card systems. ISO 7816-5 defines the AID (application identifier) data
format to be used for unique identification of card applications (and certain kinds of
files in card file systems). The Java Card platform uses the AID data format to
identify applets and packages. AIDs are administered by the International Standards
Organization (ISO), so they can be used as unique identifiers.
这章描述了在java卡CAP文件和EXP文件用来命名应用和包的机制。java类文件使用统一码字符串来命名java包，因为java卡平台不支持字符串，所以提供了另一种机制。
ISO 7816是一个用来描述构建智能卡系统很广阔范围知识的一个多部分规范。ISO7816-5定义了AID（应用标识）数据格式来唯一的标识卡片应用（和卡片内特定类型的文件）。AID由ISO国际规范组织统一管理，所以它可以用来作为唯一标识。
4.2.1 The AID Format
4.2.1 AID格式
This section presents a minimal description of the AID data format used in Java
Card technology. For complete details, refer to ISO 7816-5, AID Registration
Category ‘D’ format.
这章提供了在java卡技术中使用的AID数据的最小描述。更具体的资料，参考ISO7816-5，AID组织结构"D"格式
The AID format used by the Java Card platform is an array of bytes that can be
interpreted as two distinct pieces, as shown in TABLE 4-1. The first piece is a 5-byte
value known as a RID (resource identifier). The second piece is a variable length
value known as a PIX (proprietary identifier extension). A PIX can be from 0 to 11
bytes in length. Thus an AID can be from 5 to 16 bytes in total length.
java卡平台使用的AID格式是一个可以被翻译为两部分的字节数组，参考表4-1.第一部分是一个5字节的值，被称为RID（资源标识），第二部分是一个变长的，叫做PIX（私有标识扩展）。PIX的长度可以是0到11个字节。
所以AID可以是5到16个字节。
ISO controls the assignment of RIDs to companies, with each company obtaining its
own unique RID from the ISO. Companies manage assignment of PIXs for AIDs
using their own RIDs.
ISO控制着分配RID给各个申请RID的公司，每个公司再来在AID中管理使用PIX。
4.2.2 AID Usage
4.2.2 AID使用
In the Java platform, packages are uniquely identified using Unicode strings and a
naming scheme based on internet domain names. In the Java Card platform,
packages and applets are identified using AIDs.
Any package that is represented in an export file must be assigned a unique AID.
The AID for a package is constructed from the concatenation of the company’s RID
and a PIX for that package. This AID corresponds to the string name for the package,
as shown in FIGURE 4-1.
在java平台中，包是用基于国际域名的串唯一标识的。在java卡平台，包和应用使用AID来标识。
任何在export中提到的包必须和一个唯一的AID关联。包的AID由公司的RID和包的PIX组成，AID和包名形成对应。
Each applet installed on a Java Card technology enabled device must also have a
unique AID. This AID is constructed similarly to a package AID. It is a
concatenation of the applet provider’s RID and PIX for that applet. An applet AID
must not have the same value as the AID of any package or the AID of any other
applet. The RID of each applet in a package must be the same as the RID of the
package.
每个安装在java卡平台上的应用必须也拥有一个唯一的AID。这个AID的构建和包的AID构建类似，由应用提供者的RID和应用的PIX组成。应用的AID不能和任何包的AID相同，也不能和其它包的应用AID相同。包中的所有应用的RID必须和包的RID相同。
Custom components defined in a CAP file are also identified using AIDs. Like AIDs
for applets and packages, component AIDs are formed by concatenating a RID and a
PIX.
在CAP文件中定义的组件也是用AID来标识。和应用，包的AID类似，组件AID也遵从RID和PIX的结构。
4.3 Token-based Linking
4.3 基于令牌的链接
This section describes a scheme that allows downloaded software to be linked
against APIs on a Java Card technology enabled device. The scheme represents
referenced items as opaque tokens, instead of Unicode strings as are used in Java
class files. The two basic requirements of this linking scheme are that it allows
linking on the device, and that it does not require internal implementation details of
APIs to be revealed to clients of those APIs. Secondary requirements are that the
scheme be efficient in terms of resource use on the device, and have acceptable
performance for linking. And of course, it must preserve the semantics of the Java
language.
这章描述了允许下载的软件链接到API的方案。这个方案使用晦涩的令牌来替代java类文件中的字符串来链接对象。这种链接方案的两个需求是，它允许在不透漏任何实现细节的情况下将客户端和API链接，
第二个需求是这个方案在设备上的资源使用比较高效，并且在链接上拥有可接受的工作性能。当然它一定维持了java语言的语义。
4.3.1 Externally Visible Items
4.3.1 外部可见对象
Classes (including Interfaces) in Java packages may be declared with public or
package visibility. A class’s methods and fields may be declared with public,
protected, package or private visibility. For purposes of this document, we define
public classes, public or protected fields, and public or protected methods to be
externally visible from the package.
java包中的类可以被声明为public,或者package可见，类的方法和属性可以被声明为public，protected，package或者private属性。基于这个文档的意图，我们定义public的类，public或者protected的属性和方法为包外可见。
Each externally visible item must have a token associated with it to enable references
from other packages to the item to be resolved on a device. There are six kinds of
items in a package that require external identification.
■ Classes (including Interfaces)
■ Static Fields
■ Static Methods
■ Instance Fields
■ Virtual Methods
■ Interface Methods
每个外部可见的对象必须拥有一个令牌使得其它包的可是实现对其的引用。有六种包中的对象需要外部标识。
■ 类（包含接口）
■ 静态属性
■ 静态方法
■ 实例属性
■ 虚方法
■ 接口方法
4.3.2 Private Tokens
4.3.2 私有令牌
Items that are not externally visible are internally visible. Internally visible items are
not described in a package’s export file, but some such items use private tokens to
represent internal references. External references are represented by public tokens.
There are three kinds of items that can be assigned private tokens.
■ Instance Fields
■ Virtual Methods
■ Packages
非外部可见的对象成为内部可见对象，内部可见的对象在包的导出文件中不描述。但是一些这种类型的对象使用私有的令牌来实现内部访问。外部引用由公有令牌来实现。
有三种类型的对象可以被指派私有令牌
■ 实例属性
■ 虚方法
■ 包
4.3.3 The Export File and Conversion
4.3.3 导出文件和转化
An export file contains entries for externally visible items in the package. Each entry
holds the item’s name and its token. Some entries may include additional
information as well. For detailed information on the export file format, see
Chapter 5, “The Export File Format”.
导出文件包含包中的外部可见对象的入口，每个入口保留对象的名字和它的令牌。当然一些入口也可以包含附加的信息。更详细的内容参考第五章。
The export file is used to map names for imported items to tokens during package
conversion. The Java Card converter uses these tokens to represent references to
items in an imported package.
导出文件被用来在包转化的过程完成导入对象名字到令牌的转化。java卡converter使用这些令牌来实现导入包中对象的引用。
For example, during the conversion of the class files of applet A, the export file of
javacard.framework is used to find tokens for items in the API that are used by the
applet. Applet A creates a new instance of framework class OwnerPIN. The
framework export file contains an entry for javacard.framework.OwnerPIN that
holds the token for this class. The converter places this token in the CAP file’s
constant pool to represent an unresolved reference to the class. The token value is
later used to resolve the reference on a device.
举个例子，在应用A的类文件的转化过程中，javacard.framework的导出文件用来查找应用中使用的API的令牌。应用A创建了一个framework包中类OwnerPIN的实例，framework导出文件包含一个指向javacard.framework.OwnerPIN的入口，
用来保留这个类的令牌。converter把这个令牌放到CAP文件的常量池来表示对这个类的引用。令牌的值稍后会用来在实现引用。
4.3.4 References – External and Internal
4.3.4 引用-外部引用和内部引用
In the context of a CAP file, references to items are made indirectly through a
package’s constant pool. References to items in other packages are called external,
and are represented in terms of tokens. References to items in the same CAP file are
called internal, and are represented either in terms of tokens, or in a different
internal format.
在一个CAP文件北京下，对象的引用是通过包的常量池间接实现的，对其它包对象的引用称为外部引用，通过令牌来实现。对相同CAP文件对象的引用成为内部引用，或者通过令牌或者通过另外的内部结构来实现。
An external reference to a class is composed of a package token and a class token.
Together those tokens specify a certain class in a certain package. An internal
reference to a class is a 15-bit value that is a pointer to the class structure’s location
within the CAP file.
一个指向类的外部引用是由一个包令牌和一个类令牌组成。合到一起，这些令牌定义了一个特定包里面的特定的类。
一个指向类的内部引用是CAP中从类结构开始的15-bit的偏移值。
An external reference to a static class member, either a field or method, consists of a
package token, a class token, and a token for the static field or static method. An
internal reference to a static class member is a 16-bit value that is a pointer to the
item’s location in the CAP file.
一个指向类的静态成员的外部引用，由一个包令牌，一个类令牌，和一个静态域或者方法的令牌组成。
一个指向类的静态成员的内部引用，是CAP中存放位置的16-bit的偏移值。
References to instance fields, virtual methods and interface methods consist of a
class reference and a token of the appropriate type. The class reference determines
whether the reference is external or internal.
指向实例属性，虚方法和接口方法的引用由一个类引用和一个恰当类型的引用组成。类引用来决定这个引用是否是内部或者外部。
4.3.5 Installation and Linking
4.3.5 安装和链接
External references in a CAP file can be resolved on a device from token form into
the internal representation used by the virtual machine.
A token can only be resolved in the context of the package that defines it. Just as the
export file maps from a package’s externally visible names to tokens, there is a set of
link information for each package on the device that maps from tokens to resolved
references.
CAP文件中的外部引用可以被虚拟机在设备上从令牌转化为内部的实现。
令牌只能在定义了它自己的包的上下文中才能被解析，和EXP文件中把外部可见名转化为令牌一样，在设备上，每个包都有一系列的链接信息用以把令牌解析为确定的引用。
4.3.6 Token Assignment
4.3.6 令牌分配
Tokens for an API are assigned by the API’s owner and published in the package
export file(s) for that API. Since the name-to-token mappings are published, an API
owner may choose any order for tokens (subject to the constraints listed below).
A particular device platform can resolve tokens into whatever internal
representation is most useful for that implementation of a Java Card virtual
machine. Some tokens may be resolved to indices. For example, an instance field
token may be resolved to an index into a class instance’s fields. In such cases, the
token value is distinct from and unrelated to the value of the resolved index.
API的令牌由API的拥有者分配，并发布在API包的export file目录中。因为名称到令牌的映射已经发布，一个API拥有者可以选择任何令牌的顺序（服从下面的约束）。
可以把令牌解析为任意的内部实现的设备平台对实现java卡虚拟机是非常有帮助的。一些令牌可以被解析为索引。举例，一个实例属性令牌可以被解析为一个指向类实例的属性空间的索引。
在这种情况下令牌的值就和那些无关的有很大不同。
4.3.7 Token Details
4.3.7 令牌细节
Each kind of item in a package has its own independent scope for tokens of that
kind. The token range and assignment rules for each kind are listed in TABLE 4-2.
TABLE 4-2 Token Range, Type and Scope
Token Type Range Type Scope
包中每种类型的对象都拥有独立的令牌范围。下表是每种类型的令牌范围和访问限制。
4.3.7.1 Package
4.3.7.1 包
All package references from within a CAP file are assigned private package tokens.
Package token values must be in the range from 0 to 127, inclusive. The tokens for all
the packages referenced from classes in a CAP file are numbered consecutively
starting at zero. The ordering of package tokens is not specified.
在CAP中所有的包引用都被指派了私有包令牌。包令牌的值必须是0-127。类引用的所有包在CAP文件中连续编号，从0开始。包令牌的顺序没有指定。
4.3.7.2 Classes and Interfaces
4.3.7.2 类和接口
All externally visible classes and interfaces in a package are assigned public class
tokens. Class token values must be in the range from 0 to 254, inclusive. The tokens
for all the public classes and interfaces in a package are numbered consecutively
starting at zero. The ordering of class tokens is not specified.
Package-visible classes and interfaces are not assigned tokens.
包中所有外部可见类和接口都被分配公有类令牌，类令牌的值必须是0-254.包中的所有类和接口连续编号，从0开始。类令牌的顺序没有规定。
包可见的类和接口不分配令牌。
4.3.7.3 Static Fields
4.3.7.3 静态属性
All externally visible static fields in a package are assigned public static field tokens.
The tokens for all externally visible static fields in a class are numbered
consecutively starting at zero. Static fields token values must be in the range from 0
to 255, inclusive. The ordering of static field tokens is not specified.
Package-visible and private static fields are not assigned tokens. In addition, no
tokens are assigned for final static fields that are initialized to primitive, compile-
time constants, as these fields are never represented as fields in CAP files.
包中所有外部可见的静态属性被分配公有静态属性令牌。
外部可见静态域的令牌连续编号，从0开始。静态属性令牌值必须是0-255。静态属性令牌的排序没有规定。
包可见和私有的静态属性不分配令牌。而且被初始化为基本类型的final static属性也不分配令牌，编译期常量相当于从来没有出现在CAP的属性中。（直接把常量转化为字节码了）
4.3.7.4 Static Methods and Constructors
4.3.7.4 静态属性和构造函数
All externally visible static methods and constructors in a package are assigned
public static method tokens. Constructors are included in this category because they
are statically bound. Static method token values must be in the range from 0 to 255,
inclusive. The tokens for all the externally visible static methods and constructors in
a class are numbered consecutively starting at zero. The ordering of static method
tokens is not specified.
Package-visible and private static methods as well as package-visible and private
constructors are not assigned tokens.
包中所有的外部可见的静态方法被分配静态方法令牌。构造函数也被包含在这个范围是因为它们也是静态绑定的。静态方法令牌的值必须是0-255,静态函数和构造函数的token是连续编号，从0开始。静态方法令牌的顺序没有规定。
包可见和私有的静态方法和包可见和私有的构造函数不分配令牌。
4.3.7.5 Instance Fields
4.3.7.5 实例属性
All instance fields defined in a package are assigned either public or private instance
field tokens. The scope of a set of instance field tokens is limited to the class that
declares the instance fields, not including the fields declared by superclasses of that
class.
Instance field token values must be in the range from 0 to 255, inclusive. Public and
private tokens for instance fields are assigned from the same namespace. The tokens
for all the instance fields in a class are numbered consecutively starting at zero,
except that the token after an int field is skipped and the token for the following
field is numbered two greater than the token of the int field.
Within a class, tokens for externally visible fields must be numbered less than the
tokens for package and private fields. For public tokens, the tokens for reference
type fields must be numbered greater than the tokens for primitive type fields. For
private tokens, the tokens for reference type fields must be numbered less than the
tokens for primitive type fields. Beyond that, the ordering of instance field tokens in
a class is not specified.
包中所有的实例属性都被分配了公有或者私有的实例属性令牌。一系列实例属性令牌的范围被限定到了声明这个属性的类的范围内，不包含该类的父类所声明的属性。
实例属性令牌值的范围是0-255，公有和私有的令牌被分配到相同的命名空间。令牌从0开始顺序排列，int类型的属性将导致后边的属性令牌多增加一。
在类中，公有令牌的值必须小于私有令牌。对于公有类型令牌，索引类型的令牌的值必须大于基本类型令牌的值。对私有类型令牌，索引类型的令牌的值必须大于基本类型令牌的值。除此之外，没有别的限制。
4.3.7.6 Virtual Methods
4.3.7.6 虚方法
Virtual methods are instance methods that are resolved dynamically. The set
includes all public, protected and package-visible instance methods. Private instance
methods and all constructors are not virtual methods, but instead are resolved
statically during compilation.
虚方法是被动态解析的实例方法。包含所有public，protected和package可见的实例方法。private实例方法和所有的构造方法不是虚方法，相反可以在编译过程中静态关联。
All virtual methods defined in a package are assigned either public or private virtual
method tokens. Virtual method token values must be in the range from 0 to 127,
inclusive. Public and private tokens for virtual methods are assigned from different
namespaces. The high bit of the byte containing a virtual method token is set to one
if the token is a private token.
所有定义在包中的虚方法都被定义为公有或者私有虚方法令牌。虚方法令牌的值必须在0-127之间。公有和私有令牌被分派到不同的命名空间。虚方法令牌的最高bit是1表明令牌是个私有令牌。
Public tokens for the externally visible (public or protected) introduced virtual
methods in a class are numbered consecutively starting at one greater than the
highest numbered public virtual method token of the class’s superclass. If a method
overrides a method implemented in the class’s superclass, that method is assigned
the same token number as the method in the superclass. The high bit of the byte
containing a public virtual method token is always set to zero, to indicate it is a
public token. The ordering of public virtual method tokens in a class is not specified.
一个类中外部可见的方法对应的公有令牌从该类的父类的令牌值+1开始分配如果一个方法重载了父类中实现的一个方法，这个方法使用和父类中对应的方法一致的令牌。公有令牌的最高bit永远被设置为0,来和私有令牌做区分。一个类中的公有令牌值的排序没有定义。
Private virtual method tokens are assigned to package-visible virtual methods. They
are assigned differently from public virtual method tokens. If a class and its
superclass are defined in the same package, the tokens for the package-visible
introduced virtual methods in that class are numbered consecutively starting at one
greater than the highest numbered private virtual method token of the class’s
superclass. If the class and its superclass are defined in different packages, the
tokens for the package-visible introduced virtual methods in that class are numbered
consecutively starting at zero. If a method overrides a method implemented in the
class’s superclass, that method uses the same token number as the method in the
superclass. The definition of the Java programming language specifies that
overriding a package-visible virtual method is only possible if both the class and its
superclass are defined in the same package. The high bit of the byte containing a
virtual method token is always set to one, to indicate it is a private token. The
ordering of private virtual method tokens in a class is not specified.
私有虚方法令牌和包可见的虚方法关联，它的分配和公有虚方法令牌不同。如果一个类和它的父类在相同的包内定义，私有令牌的从该类的父类的私有令牌值+1开始分配。如果类和它的父类是在不同包定义的，那么私有令牌从0开始分配。
如果一个方法重载了父类实现的方法，则复用它父类的令牌值。从java语言规范的定义，包可见重载只会发生在父类和子类同包的情况。私有令牌的最高bit永远是1，来和公有令牌区分。私有令牌的令牌排序没有规定。
4.3.7.7 Interface Methods
4.3.7.7 接口方法
All interface methods defined in a package are assigned public interface method
tokens, as interface methods are always public. Interface methods tokens values
must be in the range from 0 to 127, inclusive. The tokens for all the interface
methods defined in or inherited by an interface are numbered consecutively starting
at zero. The token value for an interface method in a given interface is unrelated to
the token values of that same method in any of the interface’s superinterfaces. Each
interface includes its own token values for all the methods inherited from super-
interfaces as well as its defined methods. The high bit of the byte containing an
interface method token is always set to zero, to indicate it is a public token. The
ordering of interface method tokens is not specified.
所有在包中定义的接口方法都分配了公有接口方法令牌，因为接口方法总是公有的。接口方法令牌的值必须在0到127之间。所有在接口中定义或者从接口中继承的接口方法的令牌从0开始连续分配。
一个给定接口中的接口方法的令牌值和父接口中相同的方法的令牌值无关。每个接口包含所有从父接口继承的所有方法的令牌值。接口方法令牌值的最高bit永远是0，来标识是一个公有令牌。接口方法令牌的顺序未定义。
4.4 Binary Compatibility
4.4 数据兼容
In the Java programming language the granularity of binary compatibility can be
between classes since binaries are stored in individual class files. In Java Card
systems Java packages are processed as a single unit, and therefore the granulari
of binary compatibility is between packages. In Java Card systems the binary of
package is represented in a CAP file, and the API of a package is represented in
export file.
在java编程语言兼容数据的粒度是在类之间，因为数据是被存储到各自的类文件中。在java卡系统中，java包是作为一个独立的单元处理的。在java卡系统中，包的数据存储在CAP文件中，包的应用接口反映在EXP文件中
In a Java Card system, a change to a type in a Java package results in a new CAP file.
A new CAP file is binary compatible with (equivalently, does not break
compatibility with) a preexisting CAP file if another CAP file converted using the
export file of the preexisting CAP file can link with the new CAP file without errors.
在java卡系统中，对java包进行的更改会产生一个新的CAP文件。一个新的CAP文件和之前的CAP文件数据兼容的前提是：另外一个使用了之前CAP文件的导出文件的CAP包可以和新的CAP包无错链接。
shows an example of binary compatible CAP files, p1 and p1’. The preconditions for
the example are: the package p1 is converted to create the p1 CAP file and p1 export
file, and package p1 is modified and converted to create the p1’ CAP file. Package p2
imports package p1, and therefore when the p2 CAP file is created the export file of
p1 is used. In the example, p2 is converted using the original p1 export file. Because
p1’ is binary compatible with p1, p2 may be linked with either the p1 CAP file or the
p1’ CAP file.
以下例子展示了数据兼容的CAP文件，p1和p1'。例子的前提是包p1转化后生成p1 CAP文件和p1 export文件，包p1修改后并且转化产生p1' CAP文件。包p2导入了包p1，因此p2生成CAP的时候使用了p1的export文件。
在例子中，p2是使用原始的p1的导出文件。因为p1'和p1数据兼容，p2可以链接到p1 CAP或者p1' CAP文件。
Any modification that causes binary incompatibility in the Java programming
language also causes binary incompatibility in Java Card systems. These
modifications are described as causing a potential error in The Java Language
任何导致java语言层的数据不兼容的修改也会导致java卡系统的数据部兼容。这种修改在被描述成导致java语言潜在的错误。
Specification. Any modification that does not cause binary incompatibility in the
Java programming language does not cause binary incompatibility in a Java Card
system, except under the following conditions:
■ The value of a token assigned to an element in the API of a package is changed.
■ The value of an externally visible final static field (compile-time constant) is
changed.
■ An externally visible virtual method that does not override a preexisting method
is added to a non-final public class.
■ An externally visible interface method that does not override a preexisting
method is added to a public interface.
明确的说来，任何在java语言中不会导致数据不兼容的修改也不会导致java卡系统的数据不兼容。除了以下的情况：
■ API包中某对象关联的令牌值发生了变化。
■ 外部可见静态常量属性（编译期常量）的值发生了变化。
■ 在一个非最终公有类上增加了（而不是重载）一个外部可见虚方法。
■ 在一个公有接口中增加了（而不是重载）一个外部可见接口方法。
Tokens are used to resolve references to imported elements of a package. If a token
value is modified, a linker on a device is unable to associate the new token value
with the previous token value of the element, and therefore is unable to resolve the
reference correctly.
令牌被用来解决导入对象的引用。如果一个令牌的值被修改了，设备上的链接器不能把对象之前的令牌和之后的令牌进行关联，从而造成无法正确的解析引用。
Compile-time constants are not stored as fields in CAP files. Instead their values are
recorded in export files and placed inline in the bytecodes in CAP files. These values
are said to be pre-linked in a CAP file of a package that imports those constants.
During execution, information is not available to determine whether the value of an
inlined constant is the same as the value defined by the binary of the imported
package.
编译期常量不存到CAP文件的属性里面，而是被记录到EXP文件，并直接代入CAP文件的字节码中。这些值可以被认为是被在导入了这些常量的CAP中预链接了。
在执行过程中，没有足够的信息来决定是否一个内联的常数值是否和导入包定义的值是否一致。
As described above, tokens assigned to public and protected virtual methods are
scoped to the hierarchy of a class. Tokens assigned to public and protected virtual
methods introduced in a subclass have values starting at one greater than the
maximum token value assigned in a superclass. If a new, non-override, public or
protected virtual method is introduced in a superclass it is assigned a token value
that would otherwise have been assigned in a subclass. Therefore, two unique
virtual methods could be assigned the same token value within the same class
hierarchy, making resolution of a reference to one of the methods ambiguous.
在上面提到过，公有和保护类型的虚函数是属于类的范围。子类的公有和保护类型的虚函数的令牌是从父类的令牌值+1开始的。如果一个新的，非重载的公有或保护类型的虚函数被加入父类，它将被分配到子类或许已经存在的令牌值。
因此，两个唯一的虚方法可能被关联到同一个类的同一个令牌上。将会对方法的解析产生歧义。
The addition of an externally visible, non-override method to a public interface is a
binary incompatible change. It allows classes which are not themselves abstract to
contain an abstract method. For example, consider the case of an interface I
implemented by a class C that is not abstract, where I and C reside in different
packages. If a new method is added to I, creating I’, then C cannot link with the new
version of I’ because this would result in the class C containing an abstract method
without the class C being abstract. The fact that C can not link with I’ means that I
and I’ are not binary compatible.
对以个外部可见的非重载的接口方法增加是一个非兼容性的修改，它是的非抽象类拥有一个抽象方法。举个例子，假设接口I被非抽象类C实现，并且I和C在不同的包。
如果I增加了一个新的方法，产生了I‘，C不能和新版本的I‘链接，因为这会导致C中包含一个虚方法。事实上C不能链接到I’就意味着I和I‘不兼容。
4.5 Package Versions
4.5 包版本
Each implementation of a package in a Java Card system is assigned a pair of major
and minor version numbers. These version numbers are used to indicate binary
compatibility or incompatibility between successive implementations of a package.
每个java卡系统的包的实现都分配了一堆主，次版本号。这些版本号用来标明保证包实现过程中的数据兼容性的连续。
4.5.1 Assigning
4.5.1 分配
The major and minor versions of a package are assigned by the package provider. It
is recommended that the initial implementation of a package be assigned a major
version of 1 and a minor version of 0. However, any values may be chosen. It is also
recommended that when either a major or a minor version is incremented, it is
incremented exactly by 1.
一个包的主要和次要版本是由包的发行者提供。包的初始版本号可以被分配为任何值，但建议分配版本号1.0。同时建议当主版本和次要版本发生变化的时候，每次增加1
A major version must be changed when a new implementation of a package is not
binary compatible with the previous implementation. The value of the new major
version must be greater than the major version of the previous implementation.
When a major version is changed, the associated minor version must be assigned the
value of 0.
当一个包新的实现和之前版本不兼容的时候主版本必须更新。新的主版本号必须比之前版本的主版本号大。当一个主版本号更改了，相关的次要版本号必须被分配为0.
When a new implementation of a package is binary compatible with the previous
implementation, it must be assigned a major version equal to the major version of
the previous implementation. The minor version assigned to the new
implementation must be greater than the minor version of the previous
implementation.
当一个包新的实现和之前的实现兼容，它必须分配一个和之前版本相同的主版本号。新的实现的次要版本号必须比之前的次要版本号大。
4.5.2 Linking
4.5.2 链接
Both an export file and a CAP file contain the major and minor version numbers of
the package described. When a CAP file is installed on a Java Card technology-
enabled device a resident image of the package is created, and the major and minor
version numbers are recorded as part of that image. When an export file is used
during preparation of a CAP file, the version numbers indicated in the export file are
recorded in the CAP file.
exp文件和cap文件都包含包的主要和次要版本。当一个CAP文件被安装到一个java卡设备上，一个包的安装镜像就创建了，主版本号和次要版本号被当做镜像的一部分存储下来。
当一个exp文件在准备CAP文件的时候使用，export文件中标明的版本号将被记录到CAP文件中。
During installation, references from the package of the CAP file being installed to an
imported package can be resolved only when the version numbers indicated in the
export file used during preparation of the CAP file are compatible with the version
numbers of the resident image. They are compatible when the major version
numbers are equal and the minor version of the export file is less than or equal to
the minor version of the resident image.
在安装过程中，被安装的CAP文件的包的引用在如下情况下被解析：安装包中导入的export文件版本和已经安装的CAP版本兼容。当export文件中版本和已经安装的CAP的的主版本数相同，次要版本号小于等于的时候是兼容的。
6818
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
