C H A P T E R 1 - Using Object, Package and Applet Deletion

C H A P T E R 1

Using Object, Package and Applet Deletion

This chapter describes how to use the object deletion mechanism and the package and applet deletion features of the Java Card platform.

Object Deletion Mechanism

The object deletion mechanism on the Java Card platform reclaims memory that is being used by "unreachable" objects. For an object to be unreachable, neither a static nor an object field can point to an object. An applet object is reachable until successfully deleted.

The object deletion mechanism on the Java Card platform is not like garbage collection in standard Java technology applications due to space and time constraints. The amount of available RAM on the card is limited. In addition, because object deletion mechanism is applied to objects stored in persistent memory, it must be used sparingly. EEPROM writes are very time-consuming operations and only a limited number of writes can be performed on a card. Due to these limitations, the object deletion mechanism in Java Card technology is not automatic. It is performed only when an applet requests it. Use the object deletion mechanism sparingly and only when other Java Card technology-based facilities are cumbersome or inadequate.

The object deletion mechanism on the Java Card platform is not meant to change the programming style in which programs for the Java Card platform are written.

Requesting the Object Deletion Mechanism

Only the runtime environment for the Java Card platform (Java Card Runtime Environment or Java Card RE) can start the object deletion mechanism, although any applet on the card can request it. The applet requests the object deletion mechanism with a call to the JCSystem.requestObjectDeletion() method.

For example, the following method updates the buffer capacity to the given value. If it is not empty, the method creates a new buffer and removes the old one by requesting the object deletion mechanism.

/**

* The following method updates the buffer size by removing

* the old buffer object from the memory by requesting

* object deletion and creates a new one with the

* required size.

void updateBuffer(byte requiredSize){

try{

if(buffer != null && buffer.length == requiredSize){

//we already have a buffer of required size

return;

}

JCSystem.beginTransaction();

byte[] oldBuffer = buffer;

buffer = new byte[requiredSize];

if (oldBuffer != null)

JCSystem.requestObjectDeletion();

JCSystem.commitTransaction();

}catch(Exception e){

JCSystem.abortTransaction();

}

Object Deletion Mechanism Usage Guidelines

Do not confuse the object deletion mechanism on the Java Card platform with garbage collection in the standard Java programming language. The following guidelines describe the possible scenarios when the object deletion mechanism might or might not be used:

When throwing exceptions, avoid creating new exception objects and relying on the object deletion mechanism to perform cleanup. Try to use existing exception objects.

Similarly, try not to create objects in method or block scope. This is acceptable in standard Java technology applications, but is an incorrect use of the object deletion mechanism in Java Card technology-based applications.

Use the object deletion mechanism when a large object, such as a certificate or key, must be replaced with a new one. In this case, instead of updating the old object in a transaction, create a new object and update its pointer within the transaction. Then, use the object deletion mechanism to remove the old object.

Use the object deletion mechanism when object resizing is required, as shown in the example in Requesting the Object Deletion Mechanism.

Package and Applet Deletion

Version 2.2.2 of the Java Card platform provides the ability to delete package and applet instances from the card's memory. Requests for deletion are sent in the form of an APDU from the terminal to the smart card. Requests to delete an applet or package cannot be sent from an applet on the card.

In version 2.2.2 of the Java Card platform, the installer deletes packages and applets. Once the installer is selected, it can receive requests from the terminal to delete packages and applets. The following sections describe programming guidelines that will help your packages and applets to be more easily removed.

Developing Removable Packages

Package deletion refers to removing all of a package's code from the card's memory. To be eligible for deletion, nothing on the card can have dependencies on the package to be deleted, including the following:

Packages that are dependent on the package to be deleted

Applet instances or objects that either belong to the package, or that belong to a package that depends on the package to be deleted

Package deletion will not succeed if any of the following conditions exist:

A reachable instance of a class belonging to the package exists on the card.

Another package on the card depends on the package.

A reset or power failure occurs after the deletion process begins, but before it completes.

To ensure that a package can be removed from the card easily, avoid writing and downloading other packages that might be dependent on the package. If there are other packages on the card that depend on this package, then you must remove all of the dependent packages before you can remove this package from the card memory.

Writing Removable Applets

Deleting an applet means that the applet and all of its child objects are deleted. Applet deletion fails if any of the following conditions exist:

Any object owned by the applet instance is referenced by an object owned by another applet instance on the card.

Any object owned by the applet instance is referenced from a static field in any package on the card.

The applet is active on the card.

If you are writing an applet that is deemed to be short lived and is to be removed from the card after performing some operations, follow these guidelines to ensure that the applet can be removed easily:

Write cooperating applets if shareable objects are required. To reduce coupling between applets, try to obtain shareable objects on a per-use basis.

If interdependent applets are required, make sure that these applets can be deleted simultaneously.

Follow one of these guidelines when static reference type fields exist:

Ensure there is a mechanism available in the applet to disassociate itself from these fields before applet deletion is attempted.

Ensure that the applet instance and code can be removed from the card simultaneously (that is, by using applet and package deletion).

Using the `AppletEvent.uninstall` Method

When an applet needs to perform some important actions prior to deletion, it might implement the uninstall method of the AppletEvent interface. An applet might find it useful to implement this method for the following types of functions:

Release resources such as shared keys and static objects

Backup data into another applet's space

Notify other dependent applets

Calling uninstall does not guarantee that the applet will be deleted. The applet might not be deleted after the completion of the uninstall method in some of these cases:

Other applets or packages are still dependent on this applet.

Another applet that needs to be deleted simultaneously cannot currently be deleted.

The package that needs to be deleted simultaneously cannot currently be deleted.

A tear occurs before the deletion elements are processed.

To ensure that the applets are deleted, implement the uninstall method defensively. Write your applet with these guidelines in mind:

The applet continues to function consistently and securely if deletion fails.

The applet can withstand a possible tear during the execution.

The uninstall method can be called again if deletion is reattempted.

The following example shows such an implementation:

public class TestApp1 extends Applet implements AppletEvent{

// field set to true after uninstall

private boolean disableApp = false;

...

public void uninstall(){

if (!disableApp){

JCSystem.beginTransaction(); //to protect against tear

disableApp = true; //mark as uninstalled

TestApp2SIO.removeDependency();

JCSystem.commitTransaction();

}

public boolean select(boolean appInstAlreadyActive) {

// refuse selection if in uninstalled state

if (disableApp) return false;

return true;

}

...

}