JavaOne – The Java ME platform going forward

I went to a ‘birds of a feather’ session at JavaOne this evening about the way forward for J2ME. There were people from Ericsson, France Orange, Nokia and Sun. All had been involved in the latest JSRs. The comments from them were interesting, although my lack of J2ME knowledge meant I was struggling to keep up (thanks Stephen for trying to help me via IM).

What was really interesting, however, was that during the Q&A there were several quite angry questions from developers on why there was little progress on reducing the fragmentation in the specification. The problem of coding for many different devices that support different capabilities was a big concern. What was an even bigger concern was the seeming lack of control in certification of devices as matching the specification. What do you do when a device already in the market doesn’t implement the specification properly? The answers from the panel were less than helpful. In fact, their answer was “code up an application that proves the problem and send it in”. Hmmm.

This brings up the interesting point: if mobile is such a big part of the strategy going forward for Java (see my earlier post on JavaFX Mobile), why are we solving the existing problems we already have?

3 comments

Regarding API fragmentation – you can code or work around it and live with it. The fragmentation is based on hardware capabilities anyway – you always expect it to happen.

As for the devices matching the specification, well you have to try it out on a few different peices of hardware. If you’ve got a few devices to test on, you can sort out most problems related to slightly different (and legal) workings of the JVM and API’s. And that should cover most obvious problems.

The real show stopper is the security signing of applications, and that untrusted (unsigned) applications don’t get full control over permissions. That whole certifiate/signing area is a disgrace.

Example: In an enterprise app, you might want the application to start up automatically and receive and process an SMS – generally to start up unattended and do something.

Not possible. You are never allowed the permissions to do this, unless you app has been code signed. A code signing certificate costs about $200US a year. And if the device doesn’t have the matching root certificate, it won’t even install.

Why not just allow the phone owner full control over all permissions for an application? What’s wrong with allowing the user to decide what an app is allowed to do? Regardless of whether it’s signed or not?

Wish I was there!Regarding API fragmentation you can code or work aurond it and live with it. The fragmentation is based on hardware capabilities anyway you always expect it to happen.As for the devices matching the specification, well you have to try it out on a few different peices of hardware. If you’ve got a few devices to test on, you can sort out most problems related to slightly different (and legal) workings of the JVM and API’s. And that should cover most obvious problems.The real show stopper is the security signing of applications, and that untrusted (unsigned) applications don’t get full control over permissions. That whole certifiate/signing area is a disgrace.Example: In an enterprise app, you might want the application to start up automatically and receive and process an SMS generally to start up unattended and do something.Not possible. You are never allowed the permissions to do this, unless you app has been code signed. A code signing certificate costs about $200US a year. And if the device doesn’t have the matching root certificate, it won’t even install.Why not just allow the phone owner full control over all permissions for an application? What’s wrong with allowing the user to decide what an app is allowed to do? Regardless of whether it’s signed or not?Was anyone getting into a huff about this problem during the session?