[Corrected April 9, 2009: more mentions of Classic, added a conclusion]
You have been warned in the previous posts. The Connected Edition of Java Card 3.0 is very different from Java Card 2.x. But, how exactly are these two versions different? Well, there are differences at all levels, from the virtual machine to the application model and the deployment framework.
So, let’s take a close look at all these differences, going from the low-level to the high-level differences.
At the virtual machine level
At the virtual machine level, the main difference is that the Java Card virtual machine is now strongly inspired from the 32-bit CLDC virtual machine, with which it shares a lot of characteristics. Among these characteristics, we have:
- 32-bit integer by default. Yes, some of the casts are now gone for good, as Java Card 3.0 now performs 32-bit computations.
- More basic types. Java Card 3.0 now supports all standard integral types, including the (unsigned 16-bit)
charand (signed 64-bit)
- Mandatory bytecode verification. A serious security flaw is now gone, and reverse engineering a Java Card 3.0 card may well be a difficult task. Since the inspiration comes from CLDC, the verification uses precomputed stack maps.
- Standard distribution formats. Java Card 3.0 classes are compiled into class files, which are distribution inside JAR files, using standard encoding and compression.
However, some things still didn’t come to Java Card. For instance, don’t expect any floating-point numbers, as there is little use for them, and the hardware coprocessors remain a bit too expensive.
At the runtime environment level
At the runtime environment level, there is one major change, memory management. Java Card 3.0 explicitly supports temporary objects, and objects are made persistent when they become reachable from a “persistence root”. The consequence is that it is now possible to allocate objects temporarily in RAM, and they will even be automatically garbage collected.
The transaction model has also been greatly enhanced, and it is now possible to use nested transactions, using a very flexible model. In particular, it is now possible to write libraries that use transactions in a clean way.
Finally, the sharing model has been enhanced. The firewall is still around, and the basic sharing mechanism remains the same. However, it has been complemented by a few mechanisms that allow two applications to exchange object instances, making the sharing framework really usable.
At the API level
At the API level, there are quite a few significant additions. The first one is of course the
String class, which is quite mandatory is we are to handle HTML pages. Of course, this class does not come alone, and
StringBuffer and a few other friends are also present.
In fact, a significant subset of
java.util is present. In particular, it is now possible to manage data with other things than simple arrays, as
Hashtable are available. However, these are the “old” versions of the classes, as the new container framework is too complex.
In addition to these basic utilities, the Generic Connection Framework (GCF) has been imported from the CLDC core library. It allows a Java Card application to open local and network connections, and to use stream-based I/O, which can be very useful, for instance to consume incoming data.
At the security level
The Java Card 2 security model is extremely simplified, mostly because there are very few resources to protect on a small smart card. With Java Card 3, this simplified model is not sustainable, because there are many more resources that need to be protected. Therefore, Java Card 3.0 defines a permission model that provides fine-grained access control to sensitive resources. Permissions are required for many operations, such as network accesses, local file accesses, context switching, shareable object access, and many more.
Naturally, the Web framework also comes with a security framework. Application-level security for Web applications is a subset of the standard servlet security framework, as used on J2EE servers. It controls how Web applications can be accessed from various kinds of clients.
Finally, Java Card 3.0 includes a declarative role-based security model, which separates the declaration of the security rules based on abstract roles, defined at development time, from the mapping of these abstract roles to actual users and authentication means.
At the application level
Naturally, the main change is the new servlet application model, which allow Web applications to be developed and deployed on a Java Card smart card. This change also comes with another related change, at a lower level; Java Card 3.0 now defines a TCP/IP-based communication model, which allows Java Card applications to serve Web requests and to establish connections with the outside using the Generic Connection Framework.
Another important evolution for applications is the enhanced sharing framework. A major shortcoming of the Java Card 2 sharing framework is the fact that it is very difficult to exchange data between applications, because only global arrays can be exchanged (in most cases, this means that only the APDU buffer can be used). Java Card 3.0 addresses this issue by allowing applications to transfer the ownership of some of their objects to another application. With this mechanism, it becomes possible to exchange data safely between two applications. In addition, the fine-grained permissions that control sharing provide an extra protection to applications that share objects.
At the deployment level
In Java Card 3.0, an application is not simply limited to a set of classes. It also includes some static content (Web pages, images, etc.), as well as several descriptors. One of them, the manifest, contains information that should be provided by the person/entity responsible for the deployment of the application rather than by the application developer. This separation of functions facilitates the development of portable applications.
To conclude, we can also recall that, even in its Connected Edition, Java Card 3.0 remains backward-compatible with Java Card 2.x. It remains possible to run all previously developed Java Card 2.x applications. The only constraint is that the binary files need to be converted in a new format.