I will only say that the functional programming enthusiasts will have to wait, as Project Lambda, which plans to introduce closures into Java, has been deferred to JDK 8.

Throughout his presentation, Mark Reinhold has been very careful to show that all the major research and development work is performed in an open manner, and that the JCP procedures will be followed before to include anything in the language. Oracle is trying to prove that it supports the language.

About Java EE, no big news, as version 6 is less than one year old, and products are still being developed by the platform vendors. Of course, like in all other talks, there has been a reference to a Web tier, with a Web profile, RESTful services, HTML5 and JSON support and other usual suspects. Talk about strong directions … At least, the message is consistent.

Newt came Greg Bollella, talking about mobile and embedded stuff. He basically started with a statement from Oracle:

Oracle is committed to modernizing the Java ME platform

OK, message received. In practice, we are looking at an upcoming Java ME.Next, which is not yet clearly specified, expect for a few principles:

• Updates across the board (Virtual Machine, API, framework)
• Guaranteed backward compatibility
• Optional packages remain present for flexibility
• JCP principles will be followed

The Web extensions for mobile applications that I outlined earlier is also in the program. However, I got disappointed, as no formal roadmap was announced. Since they are at the prototype level right now, I am afraid that it is still going to take years to iron out the “details” and make it a final specification. Too bad, we would need that quite soon.

Then, Greg Bollella moved to his favorite topis: embedded systems. He defined embedded as covering a wide area of things that contain a processor, with software, and that are not considered as computers. With this definition, there are 1000 times more processors sold in that space than in the the workstation space. Yep, that’s a big market.

According to Greg Bollella, another trend is that all these embedded devices are producing operational data that is just not used, because there is no way to get this data anywhere. For instance, in a car, many parameters are recorded every few milliseconds, temporarily stored, and then discarded. Most likely, it could be used for something.

After building all the excitement, there was nothing real to announce. Of course, the new Java ME is going to cover these embedded systems, but we didn’t get anything resembling a feature set or a roadmap. Things are hard on the device space.

Bollella mentioned Project Verrazano, though. It is a tool that takes a JAR and a platform spec, and it generates a self-contained output JAR, with everything required, including the APIs, the VM, and whatever else is required. We learnt that HelloWorld on Java 6 can be shrunk from 58Mb to 8Mb, a 80% reduction, but still rather big (apparently, this is due at least in part to the fact that native code is not filtered intelligently). Of course, this is intended as an analysis tool, in order to determine which parts of Java are used (or not used) in embedded application, and to derive from that a specific profile. I guess that an adaptation of this project to the Java Card 3.0 Classic platform would be very practical for the generation of static Java Card products. However, I haven’t found links to this project on the Web. Let’s wait and see what happens.

Overall, not a bad general session. Oracle made great efforts to display support for Java, but the announcements were not really groundbreaking. One positive note, though: it gives hope that there will still be a JavaOne or similar event next year.

These sessions have been very different, but their combination gives a very strong orientation to the direction where mobile Java is heading:

• Nice apps for everybody. Java is available on low-end and feature phones, and these phones can enjoy nice applications, like smartphones, thanks to Java. The LightWeight User Interface Toolkit (LWUIT) is the future of Java, a library that can be ported across many devices (I have doubts, but I want to believe; something to check at the Java demos).
• Tight integration with the Web. Now, when talking about mobile apps, we need to mention HTML5, using Web Services (RESTful services, JSON, and more), and mention “tight integration”. All three speakers mentioned interesting things, in different ways.
• New APIs to access hardware. This one sounds stranger, since the availability of such APIs already is a good point for Java. However, the sheer number of JSRs is staggering, so modernizing all this makes sense. NFC was mentioned by Kurian, and payment APIs have been announced by both Blackberry (with details) and Oracle (no details).

Finally, a few highlights from the presentations. Terence Barr’s show was nice, although he ran into network problems. He has shown an example called “Meet me for Dinner”, combining locatoin-based stuff, consulting many Web services, and even using a Twitter library for using OAuth. He also promised to publish the full example, so I will wait for that. Well, maybe that in the mean time I will look at the Twitter API ME.

The keynote was the occasion to get a few numbers. The estimates are now 1.1 desktops with Java, 3 billion mobile phones, and 1.4 billion cards every year. Naturally, Thomas Kurian didn’t get the full power of Java Card yet, and simply mentioned a total of 1.4 billion cards (somehow, they all do that). We also learned from Intel that combining hardware and software improvements allowed them to make a 40 times performance increase over 5 years, which beats Moore’s law by a whopping factor 5. I guess that proper optimization can yield results.

On the mobile front, we have been announced a total revamping of the mobile platform in Project Java Mobile.Next, and I guess that we’ll have to wait for that. There are many more projects happening, including Coin, Lambda, and Jigsaw, but these are not really new (just Google the trio to find out).

OK, that wraps the day. More news tomorrow. I will also try to spend a little time looking at demos.

I cannot tell you much more about this hack, because Gowdiak asks for 20,000€ to get detailed information. However, based on the little information available, my personal guess is that the main problem is situated somewhere in the application manager. There are several reasons for that:

• First, the virtual machine is starting to be quite robust (Gowdiak has actually participated to that effort), and there have been significant reviews of the latest bytecode verifier. So, I would not say that the basic Java security features are broken.
• Then, the flaw appears to be in the management of permissions, allowing an untrusted application to run and/or be recognized as a manufacturer application (the most privileged kind of applications). This is typically part of the Application Manager.
• Finally, Adam Gowdiak claims that his attack is likely to work on other devices based on Sun’s RI of Java ME. It therefore means that part of the exploitation is in the portable part, and also that part of the attack is in the device-specific part.

There are many ways to achieve such a feast, depending on the kind of attack that one is ready to perform:

• The device’s security policy may be stored in a file. In that case, the security of Java relies on the security of the underlying file system.
• Application descriptors have to be stored somewhere. If the application manager does not check their consistency regularly, they could be modified.
• Application code is also stored somewhere. They are not supposed to be modified, but consistency checks are expensive.
• There are usually plenty of debugging features in a platform, that could be activated and used maliciously.

Exploitation of such vulnerabilities usually is surprisingly easy. One you have access to all privileges, it is quite easy to write applications that do bad things. The last thing that an attacker would need is a way to push applications without warning the user, and this could be feasible with manufacturer privileges (after all, it is practical for a manufacturer to do that). Once again, I can’t say if it is the case with this particular attack.

About Nokia, I am a bit sad that they get busted here, because they are among the good guys in terms of mobile security. I guess that this kind of publicity is the price to pay for being the world leader. The S40 platform is a bit like the Windows of mobile phones, and breaking it is more interesting than breaking any other phone platform. Also, the reaction from Nokia, as mentioned by the Register, “we do not currently believe these issues represent a significant risk to customers’ devices”, is a bit surprising, especially if we consider the definition of the issue by the same Register, “a miscreant exploiting them could do whatever they like to a Series 40 phone just by knowing the phone number”.

Finally, a note about Adam Gowdiak’s job. He did very good work in finding these flaws, and he is in trouble getting paid for it. I hope that Nokia, Sun, and others have paid the fee he asks for (which is not that big), but this remains an issue.I don’t know how much time Adam Gowdiak has spent on preparing this attack, but I am not sure that such work would be feasible in a consultancy mode. I have been involved in many security evaluations, and you don’t go very far for 20,000€. A complete security review of the S40 platform would cost may times that, and it is not that easy to find experts of Adam’s caliber. Nevertheless, the good old consultancy scheme presents some advantages for manufacturers. For instance, we at Trusted Labs have found many vulnerabilities on devices ranging from smart cards to payment terminals and mobile phones (including Java ME), but you have not heard about them, and you won’t hear about them any time soon, because all our work is performed under strong non-disclosure agreements.

Adam Gowdiak has acted responsibly by not posting any details and/or exploit code publicly. I am sure that most S40 phone owners never update their platform, so any flaw identified on such a platform is likely to stay around for years on millions of devices. Nevertheless, it is only a question of time before some bad guy gets the details of this attack: either through Adam directly (20,000€ is not that much, and some bad guys are very good at social engineering, for instance for posing as a manufacturer); or through an accomplice at a manufacturer; or even by rebuilding the attack as more and more information gets leaked.

When that happens, it will be interesting to see if it triggers a wave of malicious Java applications and other attacks on S40 devices. Only time will tell.