Sneak Preview: Java Card Tools for NetBeans IDE 6.7

I've spent the last few months collaborating with the Java Card team to create Java Card plugins for NetBeans. It's not released yet, but here are some screenshots to whet your appetite.

Java Card is an interesting platform to work with - a JVM that runs on smart cards and tiny devices that fit in the palm of your hand. As of Java Card 3.0, it comes in two flavors:

• Classic—this is the same as earlier versions of Java Card. The platform is extremely limited. For example, java.lang.String does not exist, there is no java.lang.Object.hashCode() method, no floating point numbers


• Extended—for newer, more powerful smart cards—this is new in Java Card 3.0. It supports a much more complete implementation of the Java Platform. Probably the coolest thing about it is native support for Servlets—you can actually write a web application using familiar APIs, which runs on a smart card!

 

The Java Card plugins will be available sometime after NetBeans 6.7 is released, on the update center, at or near the same time that the Java Card 3.0 Reference Implementation is released. We're finishing the legal process to move the source code for the plugins into NetBeans source repository, and that should happen soon.

Setting up a Java Card platform is done using Tools > Java Platforms, just like setting up another JDK.

 

Once you have set up a Java Card platform, it is visible in the Services tab in the IDE. One "platform" may have multiple "devices". You deploy a project to a specific device on a specific platform.

 

You can change the platform and device a project deploys to at any time, in the project's customizer.

 

There are several kinds of Java Card projects you can create. All of them are built with Apache Ant, just like NetBeans Java SE projects.

 

Classic Applet projects create a traditional Java Card applet for smaller devices, just like the applets used in Java Card 2.0 and older. Classic library projects are like Classic Applet projects, without the applet—it's some code that you expect to be on the device, that might be shared between applets.

Extended Applet and Library projects use the extended API in Java Card 3.0—so you can use java.lang.String and so forth. The boot classpath will be different for Classic and Extended projects, so, for example, code completion will not show java.lang.String in Classic projects, but will in Extended projects.

 

 

Web Application projects are probably the coolest feature of Java Card 3.0. You get a skeleton project with a Servlet implemented, and you have access to the full Servlet API. This is vastly easier to work with than either of the Applet-style application types—you don't need any special code on the client to interact with an application running on a device, just a web browser! You can test your applications locally using the Reference Implementation and your desktop web browser.

 

Working on a Java Card web application is just like working on any other web application that you deploy to a servlet container.

 

Java Card involves two bits of arcana which you don't encounter in other Java platforms:

• Application Identifiers (AID)—these are unique identifiers that look like //aid//720A75E082/0058AEFC20. The first wad of hexadecimal is a vendor ID (you get one from the International Standards Organization (ISO)); the second part is a unique value you come up with. AIDs are used to identify applet classes, Java packages (classic applet & classic library projects only), and unique instances of applets (you can deploy the same applet multiple times on one device — the instance AID is used to select which applet to send information to).
• APDU scripts—these are scripts to send data to an applet. It involves a somewhat sadistic amount of hand-typed hexadecimal; the script needs to select a specific applet instance, and then send data to it.

While these two things are somewhat complicated, the NetBeans plug-ins do their best to abstract away the complexities of dealing with them, as follows:

• When you create a project, reasonable values for Applet AID, Classic Package AID, and one Instance AID are automatically generated.
• When you select the Applets tab in the Project Properties dialog, the project scans its classpath for all Java Card applet subclasses it can find:

  

   

• Once it has found them, the dialog allows you to select what applets are actually deployed, and customize the AID values used, deployment parameters and so forth. The IDE validates all of the data you entered, so that it is hard to enter invalid data:

  

   

• If you want to deploy two instances of the same applet, you can set that up as well; however, for simple cases where you just want to deploy one applet instance, you don't need to think about it:

  

   

• For testing running applets, you do not need to hand-write an entire APDU script—you can use the built-in Console to interact with deployed applets directly:

  

   

  

   

• The "package AID" for Classic projects (they are only allowed to contain one Java package) is also taken care of by the IDE, but is customizable.

  

   

• I mentioned that part of all AID values in your projects will be an ISO-assigned vendor ID (called the RID). For quickly getting started, the IDE will generate a random value for the RID, which is fine for development and testing. If you have an offical RID, you can set that up in Tools >Options; it will be used for all new projects, and clicking the Generate button in the project customizer can update the values in existing projects.

  

   

Currently the tools only support the Java Card 3.0 Reference Implementation, but that will change in the near future (I need to get my grubby paws on some actual cards). The design of the tools is extensible — in fact, the platform and device definitions are simply Properties files which are imported by the build script. The card vendor provides a set of Ant tasks for deployment to the actual device. So the projects created are not IDE-specific at all.

We're in the home-stretch of getting these plugins out the door and available to everyone using NetBeans—hopefully we'll also be able to bundle the Java Card runtime so that you can get everything you need to play with Java Card in one simple download. Look for more news soon!

A lot of the credit for these modules goes to Anki Nelaturu and the rest of the Java Card team, who created the first draft of these plugins, and who have been fantastic to collaborate with over the last few months.

From http://weblogs.java.net/blog/timboudreau/archive/2009/05/sneak_preview_j.html