But nobody ever used it. Nobody.

Why so? Because it solved the wrong problems. My passion at the time was to make developers’ life easier, and this passion was shared by many other members of the original GemXpresso team. We believed that making smart card application development available to many developers in a simple way would necessarily generate the next “killer app”. Of course, it didn’t, because the problem is not with the developers.

A smart card is not the Internet, and the next killer app will come from somebody who has a great idea about a novel way to establish trust between two entities, or something like that. And that guy will then subcontract the development to one of the happy few guys in the world who know how to write good Java Card code, optimized and secure.

So now, Java Card RMI mostly represents a few kilobytes of dead code in every Java Card on the market. Maybe that one of your cards is able to do RMI and you don’t even know it. Don’t worry for the future, the designers of Java Card RMI are still very much involved in the design of Java Card 3. We will most likely make a few mistakes in our design, but not this one.

To end with a happy note, it has been said that Java Card 3 would be fully backward compatible with Java Card 2.x, and it most likely will be true. Java Card RMI will then lie dormant in many more cards of the next generation. And maybe someone will use it.

• 60 is the NULL byte, used to get additional time.
• Status words starting by 6X (except 60) have a “meaning [that is] independent of the application”.
• Status words starting by 9X (except 9000) have a “meaning [that] relates to the application itself”.

What that means is that the GSM specs are correctly defined, as they use 9X status words for application-specific statuses, but the Java Card spec is not correct, since it defines the 6999 status word, which is reserved by ISO7816 for future use. On the other hand, one can argue that the meaning of 6999 is independent of the application. Still, not perfectly clean.

The ISO7816-3 specification provides meanings for a few 6X status words, and the ISO7816-4 specification provide a few more. The list provided in ISO7816-4 is as follows:

• 61XX: Normal processing, XX indicates the amount of data to be retrieved.
• 62XX: Warning, the state of persistent memory is unchanged. The command succeeded, possibly with restrictions. Typically used to signal blocked applications.
• 63XX: Warning, the state of persistent memory is changed. Typically used to indicate the number of attempts left on a PIN code after a failure.
• 64XX: Execution error, the state of persistent memory is unchanged.
• 65XX: Execution error, the state of persistent memory is changed.
• 66XX: Security-related issues.
• 6700: Transport error. The length is incorrect.
• 68XX: Functions in CLA not supported (since 2005).
• 69XX: Command not allowed.
• 6AXX: Wrong parameters P1-P2 (with details).
• 6B00: Wrong parameters P1-P2.
• 6CXX: Wrong Le field. XX indicates the appropriate length.
• 6D00: The instruction code is not supported (usually with XX=00).
• 6E00: The instruction class is not supported (usually with XX=00).
• 6F00: No precise diagnosis is given

The ISO7816-4 defines many more SW2 values (around 40), and it also defined a few important rules, which can be used as good guidelines:

• 61XX and 6CXX are different. When a command returns 61XX, its process is normally completed, and it indicates the number of available bytes; it then expects a GET RESPONSE command with the appropriate length. When a command returns 6CXX, its process has been aborted, and it expects the command to be reissued. As mentioned above, 61XX indicates a normal completion, and 6CXX is considered as a transport error (defined in ISO7817-3).
• Except for 63XX and 65XX, which warn that the persistent content has been changed, other status word should be used when the persistent content of the application is unchanged.
• Status words 67XX, 6BXX, 6DXX, 6EXX, and 6FXX, where XX is not 0, are proprietary status words, as well as 9YYY, where YYY is not 000.

Note that the last point extends the realm of the status words that can be defined in a proprietary way. However, Java Card’s 6999 remains a violation of the rule.

Java Card RE implementers shall also define other behaviors of their Installer, including (…) what happens if an exception, reset, or power fail occurs during installation.

In most Java Card implementations, the GlobalPlatform card specification is used as a reference for the implementation of the Installer. An applet’s install method is invoked during the execution of an INSTALL [for install] command, and the definition of this command does not define any precise behavior if the installation of the application fails.

In practice, many different cases may occur. First, it depends on when the application fails

• The application throws an exception before to invoke Applet.register. In that case, according to the Java Card specification, the installation is deemed unsuccessful. The INSTALL command shall therefore fail.
• The application throws an exception after invoking successfully Applet.register. In that case, according to the Java Card specification, the installation is deemed successful, despite the exception. In that case, the outcome of the INSTALL command is not completely clear.

• The application throws an ISOException. If this occurs in the Applet.process method, the exception’s reason is returned as status word.
• The application throws any other exception. If this occurs in the Applet.process method, the Java Card RE returns the status word 6F00 (Unknown error).

These different cases lead platform developers to make two choices: whether or not to the INSTALL command shall succeed if an exception is thrown after successful registration, and which status word to return when the INSTALL command fails. On the first issue, there are two possible interpretations:

• The INSTALL command should fail whenever the install method ends with an exception. The rationale behind this choice is that an error should never go unnoticed, and that the user needs to be warned of the error.
• The INSTALL command should succeed whenever the applet instance has been successfully registered. The rationale behind this choice is that the result of the INSTALL command shall reflect the overall result of the execution, i.e. the fact that the instance has been registered.

About the exception to be returned, there also are several possible interpretations:

• The INSTALL command should return the same status word as the Java Card RE would return from the Applet.process method. The argument is here that the information provided by the application about the reason of the failure should not be lost.
• The INSTALL command should always return a status word listed in its specification. This means that the status code implied by the exception shall be ignored, and that a standard GlobalPlatform exception shall be returned, for instance 6400 (No specific diagnosis) or 6985 (Conditions of use not satisfied). The argument is here that a GlobalPlatform command should not return status words that the terminals may not expect.

In both cases, the arguments from both sides are acceptable, which means that there is no strong decision to take. My own opinion is that the INSTALL command should succeed whenever the applet instance has been successfully registered, and it should always return a status word listed in its specification.

The conclusion is that an application should not rely on any of these behaviors if it needs to be portable between platforms. The best solution is to avoid throwing exceptions (a simple return before registration is enough to abort the installation), and to avoid putting code after the call to Applet.register. This is easy to do, except for SIM Toolkit applications, which usually need to do some operations after the applet’s registration. We’ll see how to do that correctly in another post.

• The runtime environment uses exceptions to signal errors such as null pointers, attempts to access an array outside of its bounds, or more specific details like attempting to allocate a crypto engine that is not supported.
• The application uses exceptions to signal its own errors, and abort the execution of the currently executing code.

In the case of Java Card, there is one additional use for exceptions:

• The ISOException type is used to return a status word to the card terminal if the execution of the application ends with an instance of it. Any other exception yields a 6F00 status word (meaning “Unknown error”, not very useful).

We will here focus on the use of exceptions by applications as means of internal communication (i.e., excluding the use of ISOException). The following rules can be considered as good practice:

• Catch all the exceptions you throw.
  As a stray exception will trigger a 6F00 status word, this seems quite natural.
• Use checked exceptions / Don’t use runtime exceptions.
  These two guidelines are the same. Using checked exceptions guarantees that exceptions must be declared. Runtime exceptions, beyond the fact that they are not checked, are the exceptions used by the runtime environment, and it is better not to confuse the exceptions.
• Don’t define new exception classes.
  Defining an exception class is difficult in Java Card. In addition, the exception instances managed by the JCRE are all JCRE entry-point objects, which can be very practical in many situations.

This sounds quite difficult, but Java Card offers a solution, which is to use the UserException class. It is a standard exception, it is a checked exception, and you have to catch all instances. The following example can be considered as good practice:

public static final short RS_LOW_BALANCE ;

public short debit(short value) throws UserException
{
  if (value > balance)
    UserException.throwIt(RS_LOW_BALANCE) ;
  balance -= value ;
}

The important thing is here that the throws UserException clause is mandatory (otherwise the compiler wil fail). Since the Applet.process method does not have such a clause, it means that the compiler will ensure that all exceptions are caught, enforcing the good usage guidelines all by itself.

Exceptions also need to be caught. It is possible to do it as soon as possible (in the same method, or in the calling method), or to do it much later. But this is another discussion, for another post.