The basic idea is that small embedded systems are faced with a big dilemma: if they use a simple runtime OS, there is no application portabliity and flexibility. If they add a Java runtime, then they exceed their memory requirements.

Java Card 3.0 runs on the “bare metal”, without an underlying OS. It is not alone to do so, as you can also run Java ME or .NET Compact framework on bare metal. Java Card 3.0 does not even have the smallest footprint, since the IMP profile of Java ME is smaller in code size (not in RAM usage). However, the functionality offered by IMP is quite limited, as it only offers

The main advantage of Java Card 3.0 is that it offers a unique mix of things, and that in a footprint that is close to IMP, you can get much more functionality, including:

• A strong security model, allowing several applications to share the same runtime, and even to collaborate, while guaranteeing their isolation.
• A full Web server and Web container, with the possibility to dynamically generate content.
• A good level of manageability, provided by the GlobalPlatform, which has been proven correct on deployments of millions of units (of cards).
• A high level of security, which may be a requirement for some application providers, if they are going to store locally some information on a local device.

The presentation even includes use cases. One of them is an Electronic Health Record (more on that in two hours from now, since there is a dedicated presentation on this).

Another use cases are sensors and M2M devices. In this use case, persistent data is a very strong advantage, because a Java Card system only needs to run when it needs to (i.e., when performing a measurement), and it can boot really fast. For a sensor, this translates immediately in battery lifetime, and it can mean that a small and cheap solar panel can provide sufficient power, making maintenance much simpler. Also, Java Card 3.0 offers both a HTTP server stack, to remotely manage devices or to query a sensor, and an HTTP client stack, allowing devices to push information if needed.

The last use case is about home automation. The requirements of specifications like UPnP or DLNA are quite simple, and Java Card 3.0 is a good candidate for implementing them at a very small cost, either for enabling an existing device, as an extension or companion product, or for building new kinds of devices, including Java Card 3.0 in the basic software for this.

Laurent Lagosanto also proposed a few evolutions of the spec:

• The first one is to build a “Static Edition”, in which dynamic loading is forbidden. This leads to footprint reduction, and the price to pay is that only data updates would be allowed. Actually, I am not even that pessimistic; in a device with reduced security requirements, updating the “binary” platform code with the edition would still be possible; the only limitation is related to trust, as a single person would be allowed to perform such updates.
• The second one is to remove APDU’s in an “embedded” profile. That’s obvious: outside of a smart card, who needs APDU’s?
• The third suggestion is to add a Main entry point, in order to allow the platform to get triggered without acting as a servlet. I am not sure that this is really needed, as Java Card 3.0 offers tasks, which can restart a thread at every boot; this is quite close from running a Main method.
• The last suggestion it to support real-time Java, which sounds quite interesting, even though I really have no clue about it. Some challenges have already been identified, such as garbage collection predictability (especially with slow persistent memory).

That presentation was interesting, and I hope that some guys that are interested in the Internet of Things will have liked it. Not sure, because there were no questions from the audience.

My personal opinion is that practice transforms a “basic” unwanted e-mail sollicitation (which is annoying enough) into full-fledged spam, mostly because they use a deceptive trick to get their message through. I am not sure what the benefit is for the companies that use these techniques, but I am quite glad that my mail reader doesn’t follow any links (including images) by default, so I can’t be counted as somebody who actually read the message (and help the company that markets this make money).

Another funny thing is that I have not been able to find anybody complaining about this on Goolge, most likely because I don’t have the right search words. I am sure that I am not the only one to dislike this deceptive marketing technique, and I hope that the companie that use it will soon realize that it is actually hurting their business.