Java card 3 released

SUN is about to release the newer java card 3! Quoting the wikipedia article:

Java Card refers to a technology that allows small Java-based applications (applets) to be run securely on smart cards and similar small memory footprint devices. Java Card is the tiniest of Java targeted for embedded devices. Java Card gives the user ability to program the device and make them application specific. It is widely used in SIM cards (used in GSM mobile phones) and ATM cards. The first Java Card was introduced in 1996 by Schlumberger‘s card division which later merged with Gemplus to form Gemalto. Java Card products are based on the Java Card Platform specifications developed by Sun Microsystems. Many Java card products also rely on the GlobalPlatform specifications for the secure management of applications on the card (download, installation, personalization, deletion).

Here are some features of it (text stolen from here):

  • JDK6 Compatible VM: Except for floats, it support class file version 50.
  • Full Java Language support: Java Card 2 has restrictions on the language itself. But JC3 has no limits. You can use all language features like annotations, enhanced for-loops etc… (except floating point)
  • Rich API: This is mixture of CLDC, GCF, Servlet, JavaCard2 API, Sockets, Threads, Transactions…
  • Three application models and two library models, which makes it possible to have virtually any kind of secure application on JC3: o Servlets, extended-Applets, Classic-Applets o Extension-Library and Classic-Library
  • Servlet Container with Servlet 2.5 support.
  • HTTP and HTTPS interface: No need for special client programming. Use any web client to reach JC3.
  • Still tiny(!!):24K RAM, 128K EEPROM, 512K ROM with a 32 bit processor
  • It is not just “Card” any more: With the newly added USB interface this technology can go beyond Smart Cards into devices like secure USB tokens, Secure Personal Databases, Embedded Servers, WebDAV compliant thumb drives and more.

The hot part is that smart cards support directly HTTP/HTTPS. This means it can be part of WoT and support natively Web-based communication (HTML/SOAP/REST), so it could be very nice to see new applications that could be built with it. Any experience on your side with that?

You may also like...

  • very interesting! HTTP support is good and essential, but is it just naked HTTP (i.e., the ability to compose HTTP requests and parse responses)? asks for a little bit more, so that for example instead of composing HTTP messages, there should be built-in support for local caching (if required and possible), redirections, content negotation, and all the other things that are really useful for accessing RESTful services.

  • What does it mean by releasing the java card 3.0? Does that mean that some real cards are going to available for developpers? The specifications of the JC 3 are in Sun’s website since a whiles In fact it had even iterated to 3.0.1

    Anyway, that is a great step to move smart cards to a more open platform towards the web of things. In fact the missing point would be to have more connectivity, but there are some initiatives on making the smart card a more connected object, both physically (radio interfaces) and logically (smart card web server and native tcp/ip)!

  • @Thomas: right, the spec was released by Sun a while ago what’s still missing are real cards…

    @Dret: I would be indeed surprised if the support for the whole “toolbox” you mention was already there. However as you see Restlet and Jersey being adapted to every platform you can think of lately (e.g. mobile phones) it gives good hope.

    @Vlad: SOAP on a SIM card? I’ll turn back to analog voice communication after that post… 🙂

    Anyways it still does sound promising! There was a very nice talk on the topic at Jazoon 2009 given by Sebastian Hans from Sun Microsystems! It’s worth checking it out!

  • Yeah, I join Dom in the direction that it doesn’t necessarily make sense to have all these complex features to be available on a chip, because it’s not designed to act as a larger “server” where different clients could read different data.

    I rather as a simple client and server mainly for enabling ad-hoc 1-to-1 interaction (with a card reader in a bank, shopping mall, room, etc), without requiring all chip software and hardware manufacturers to use a proprietary chip protocol.