When we first presented GemXpresso in 1997, it was made by a bunch of (Gemplus) researchers. We were all very happy, because it was a very nice card, and because it was very simple to program, thanks to Remote Method Invocation (RMI), which freed us from these damn APDU’s. It was possible to generate automatically the code that interfaces the card application with its client application on the terminal.
10 years later, RMI on Java Card has been a great success. It generated a few publications, got us to San Francisco and JavaOne a few times, and it was even incorporated in the Java Card 2.2 standard as a mandatory feature, a few years ago. Even better, it was mentioned in JSR-177 as one of the ways to communicate between a phone and a smart card. This made us all very proud.
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.
No comment.
I thought that this post was a bit depressing, but Jean-Jacques’s comment brings depression to new and unknown levels.
This “No comment” tells me that the post is right, where I kinda hoped that it was not.
It may well be that Java Card RMI is not used by any application, however it has been useful, once. During JSR 177 discussions, a well known mobile phone manufacturer from Scandinavia was strongly opposed to the APDU API supported by the mobile operators. Negotiations where blocked. Until somebody proposed to have both: APDU API *plus* Java Card RMI API, which was satisfactory for everybody.
Nowadays, JSR 177 APDU API is used in some satellite TV decoders (not exactly it’s intended use). Which would not be possible if Java Card RMI had not existed. Things are rarely useful the way it was expected or designed for, does not mean they are useless
Since .Net card is just freshly served on the table, i really can not see the java card 3 going nowhere.
This does not seem like the right article to comment on Java Card 3, but I need to answer to that.
I will make it short. .Net cards are great to work with Windows and the Microsoft ecosystem, and Java Card 3 is great to work with the Web at large.
There is room for both approaches, even if I personnally think that Java Card 3 is more likely to win this one.
[…] Have you seen any mobile device with support for JavaCard RMI? My friend, Eric Vétillard explains why. […]