Remuneraciones

created the ^export file of ^p1 is used. In the example, ^p2 is converted using the original ^p1export file. Because ^p1’ is binary compatible with ^p1, ^p2 may be linked with either the ^{p1 CAP} file or the ^{p1’ CAP} file.

FIGURE 4-4 Binary compatibility example

p2

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 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 ^finalstatic field (compile-time constant) is changed;

■ an externally visible virtual method that does not override a preexisting method is added to a non-finalpublic class.

■ an externally visible interface method that does not override a preexisting method is added to a public interface.

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.

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.

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.

4.5 Package Versions

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.

4.5.1 Assigning

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.

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.

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

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 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.

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.

C H A P T E R

5