So, the news is in the directions. And we have had one direction set for Java Card. Java Card will take a greater role in the embedded world in the next years, with an objective to provide a nice security subsystem to all devices, and even more so when these devices run Java. Now, you know what keeps me busy, so stay tuned for more news, but not at this JavaOne.

AMD is then talking about hardware tendencies, with more cores, and now, heterogeneous computing, with a CPU and a GPU on the same chip, using the same memory. AMD has also announced an heterogeneous platform combining a x86 CPU and a TrustZone-based GPU.

We also get the news about the recently released Java Embedded Suite 7.0, which complements Java ME with Java DB, a database, and an embedded version of Glassfish. This is one of the smallest embedded Java Web server available, but still larger than Java Card Connected. Their market could be much larger, though, as they target gateways and similar devices.

We then got Gemalto on stage, or Cinterion, a Gemalto company, announcing that their new 3G controller, with Jave ME Embedded, to make thei job simpler, and telling that Java is helping them to remove the complexity barrier in M2M, helping people to deploy edge devices. Good vision.

Than, the Royal Canadian Mint, about Java Card. Talking about MintChip, the “evolution of currency”, basically money on a smart card. Not necessarily entirely new, but it is interesting because it is combining classical and online uses. They chose Java Card because it is widespread, secure, and it supports many applications that will be useful to combine with their application. Basically, the ecosystem got them. We are just missing the developers, and there are many opportunities everywhere, for Java Card application developers, and more surprisingly for Java Card platform specialists, from new entrants in the market, who are now developing their own implementation.

OK, a good start.

On the good side, Oracle has shown some commitment to a Java roadmap, and this enormous conference has proven that Oracle plays at a different level; this may be very good for some technologies, if Java is able to find its place in the Oracle offer.

On the bad side, mobile did not look very good. Strong words were spoken about commitment, but the roadmap is not clear. Even worse, there were few exhibitors from the mobile world at JavaOne (a few at Oracle OpenWorld, but that’s another story), and it basically left me uncertain about the technology. The only message seems to be that Java is dominant on low-end phones, and that LWUIT and the upcoming Web extensions will bring smartphone apps to all these basic devices. I guess that we will have to wait to see how these features get supported by major OEM platforms.

In technical terms, the main tendency has definitely been the integration of Web applications with Java applications. HTML5 renderers and JavaScript /REST oriented tools/APIs were everywhere, from servers to mobile phones. Of course, JavaFX was also mentioned in almost every talk, but since I did not hear anybody boasting deployment/usage numbers, I guess that it’s still going uphill.

Now, if anybody from Oracle strongly disagrees with these candid views, feel free to provide an alternative view in comments. I would love to be proven wrong on my mobile feeling.

The idea of the Mobile Telephony API is that we now live in a connected world, and that we want to get applications that would allow us to control the way our device communicates, for instance to setup conference calls within an application.

In standard MSA 1.0, we get the ability to use HTTP(S), or Web Services. We also have the ability to use SATSA to communicate with a SIM card that, in turn, would have SIM Toolkit applications written in Java Card. This is interesting to work on mobile telephony and payment, but how can we do better with dedicated APIs?

The Payment API is a common front-end that is complemented by payment adapters, representing a particular payment method. It is oriented towards micropayment, and the idea is to use a simple API, and to put all the configuration information in the JAD file (that’s interesting for a security guy, because JAD files are not signed, so there may be some opportunities to get free stuff).

The Mobile Telephony is used to control calls, receive event changes of network state (YES, an application may know when we are roaming!), and a few more things. There is even a package that allows an application to get information about the money that a call costs; this is quite surprising, because this is well known for being very difficult to figure out. Like the payment API, the API is very simple, which looks quite good.

The real problem is mobile support for these optional APIs. We’ll have to see if support picks up with the maintenance release.