Depending on the applet, it would have to switch case on each individual CLA, INS, and P1/P2 to process the necessary command. This method of transmitting data can be a tedious job and a maintenance nightmare. The Java Card RMI makes it easier to perform a command.

More Algorithms
For the implementation of security algorithms we must rely on the individual vendors. Some vendors implement cards that contain just DES and Triple DES, while others implement DES, Triple DES, and RSA. For the implementation of RSA it's common to also include a crypto-coprocessor in the smart card chip to help speed up the calculations.

In Java Card 2.2, AES and elliptic curves are added. New key lengths are also available with these new algorithms. Of course, this can be a headache involving export restrictions, so check with your vendor to see what's actually implemented and what key lengths they support.

You can still perform digital signature and random number generation on the card as you did with Java Card 2.1.x.

Applet/Package Deletion
Applet/package deletion has been a hot topic since the first release of the Java Card. This feature of 2.2 will be up to individual vendors to support, utilizing their own implementation. But nonetheless, it's sure to be available since engineers and others will be requesting the functionality. Applets created using the Applet.register() methods exist until deleted by the applet deletion manager. This manager can be an applet provided by the vendor and is selectable by providing an application identifier, AID. Sun wanted to leave the implementation of the applet deletion manager up to the vendors and, because of that, the AID won't be standardized but it must be SELECTable. As long as the vendors provide a SELECTable behavior to the outside world, they can implement the applet deletion manager any way they see fit for their Java Cards.

Memory Resource Management
The JCSystem class offers two new methods: isGarbageCollectionSupported and requestGarbageCollection. These offer limited garbage collection support to query if a vendor has implemented garbage collection functionality and to request that the action be carried out. Garbage collection isn't a requirement, and once again it's up to the implementers. However, you can now query the amount of memory available to the applet, which wasn't available in 2.1.x.

JCSystem.getAvailableMemory is a nicer way to query if memory is available before you allocate it. In 2.1.x, you cross your fingers and hope that the memory is available when you allocate it, otherwise you'll receive an exception.

Logical Channels
In Java Card 2.1.x your commands are processed by the currently selected applet. Java Card 2.2 allows up to four sessions to be open, one session per logical channel. Now applet instances can be selected on different logical channels. The applet can take advantage of multisession functionality and can be concurrently selected with another applet on a different logical channel. The applet can even be selected multiple times. There is a basic logical channel, logical channel 0, that is activated upon a card reset. A card reset can occur when the card has been powered down via card removal or electrical failure.

Applets that are capable of being selected on multiple logical channels at the same time are called multiselectable applets. These will have the same security constraints as in Java Card 2.1.x with regard to active contexts. To forward APDU commands to a logical channel, the command will contain encoding in the header CLA byte to denote which channel. For example, CLA byte 0x02 could denote logical channel 2, and 0x00 could denote logical channel 0. The logical channel is of key importance for wireless support involving 3GPP, WAP, and ETSI.

Conclusion
Java Card 2.2 includes support for contactless smart cards. These cards don't have the visible chip on them, but can be read if the card is simply waved within a certain proximity of a contactless CAD. There has been movement to include some form of biometry in the Java Card API, and this technology will no doubt be appearing on the market soon.

With the new Java Card specification, existing features, such as transaction processing (much like commit/rollback in a database), become more powerful.

Personally, I'm excited about the RMI specification and memory management features that will make complex Java Card engineering a lot friendlier.