JavaME is \*not\* dead!

It's growing up. Sheesh. Some folks are far too eager to misinterpret statements and put words in my mouth. The early versions of JavaME were very simple and limited, a direct reflection of the fact that early phones themselves were simple and limited: we had to work with what we had. But as time has passed, and cell phones have become more powerful and capable, JavaME has grown up too. Cell phones are becoming the new desktop. We've been saying this for years. Over time, it's pretty clear that JavaME and JavaSE will converge and become largely indistinguishable. It goes both ways: JavaSE has a much more sophisticated graphics API, and JavaME is growing there. JavaME has a location API (GPS) and one could easily make the argument that it should be available in JavaSE.

This is a process of evolution, not "out with the old, in with the new".

JavaFX mobile contains within it an implementation of JavaME. It is not some weird new beast.


Thank you for clearing that up.

I'll step back from the ledge and write some more JavaME now. :)


Posted by Shawn on October 23, 2007 at 06:24 AM PDT #

JVM implementation quirks aside, JavaME is pretty neat! It still brings a smile to my face to see the same binary run on a range of handsets from different manufacturers. The quirks are a lot less painful than people claim they are.

However, I feel that the MIDlet signing process is completely killing innovative ideas in J2ME,

For example, the Location API (JSR-179) of which you speak requires a signature from the Unified Testing Initiative (at least on Motorola handsets). Even Verisign and Thawte are not enough. That's about $200 per test, per handset... which is quite an entrance barrier when you consider how many devices (and bugs!) are out there!

Some manufacturers allow uploading certs on a per-device basis (thank you Nokia!), but others require you to be developing for a company and go through a 3 month long application process to develop on a single device (\*cough\* Motorola \*cough\*). It's madness!

The UTI also perform automated tests which completely destroy the "write once, run anywhere" slogan which \*is realistic on J2ME\*. Specifically, they scan for the use of optional system classes and limit your device's test domain accordingly. This means you cannot write code which only run some routines (e.g. using the Bluetooth API, JSR-82) if the appropriate support is available.

The entire Security model could do with a sanity check... reminding the manufacturers that signing should not be a necessity. User permission alone should be enough. Signing should only be used for confirming identity, not for "trust"... which is a completely different thing.

Posted by Sam Halliday on October 23, 2007 at 07:58 AM PDT #

Sam: "It still brings a smile to my face to see the same binary run on a range of handsets from different manufacturers."

They all run ARM CPUs. It's about as surprising as seeing an application run on a range of PCs from different manufacturers. If anything, it's sad that the native binary solutions do the job \*better\* than Java. (Of course, with business model garbage to muck things up. :6)

Posted by josh on October 23, 2007 at 10:18 AM PDT #

"The quirks are a lot less painful than people claim they are."

--Are you serious? Have you tried to do something multimedia on a j2me phone, and see how ridiculus the implementation is done from the manufactors. Even smiliarly identical phones have bugs and differences in implementations.

Sun did a really really poor job in making sure J2ME was implemented well and according to real standards from all manufactors. Sorry, but I feel Flash (or Air mobile), and Silverlight will eat Sun's lunch when time comes from the J2ME replacement.

J2ME's moto is: "build once, debug everywhere".

Posted by ardit on October 23, 2007 at 10:34 AM PDT #

"It still brings a smile to my face to see the same binary run on a range of handsets from different manufacturers."

Me too! But only because this NEVER HAPPENS. There is no way you can release a J2ME app on a device that you've never seen, which comes at a huge cost to us small shops. Motorola phones tend to use different softkey codes. The Blackberry 8800 can't clip images properly, but the 8100 and 8700 are fine. SOME Samsungs have extremely wacky audio behavior (if you don't use their proprietary API), some don't double buffer when they say they do. That's just what I ran into today.

There's a reason that entire companies exist to do your "porting" for you to support different handsets. That reason is simply that Java ME is a very poorly controlled standard.

I agree that something newer, like Flash Lite, is well poised to step in and win, just like Flash filled the gap on the web when Java applets failed the same way.

Posted by Jesse on October 23, 2007 at 01:53 PM PDT #

J2ME is indeed a very frustrating technology from a developer's point of view.

One thing I'd like to mention though is that it has become such an ubiquitous technology for the very same reason it is frustrating: loose spec. If the specs were too restrictive - or Sun was enforcing a common behaviour - I don't think manufacturers would have made the extra efforts to put java on their device. And today we wouldn't have a common platform to develop apps on millions of devices, regardless of how painful it is.

Posted by Ludovic on October 23, 2007 at 05:33 PM PDT #


I think someone should clear that up in the JavaFX Mobile website.
As I guess many people I really thought JavaME was dead.
And at the same time, I would like to really know when JavaFX Mobile will be available on phones. Or if it's a way to install it in my current cellphone.

Posted by Pablo on October 23, 2007 at 10:34 PM PDT #

So, are they going to finally implement jsr 82? That's a very notable obmission in j2se.

Posted by ed on October 23, 2007 at 11:03 PM PDT #

Well, javaME is not dead, but it is in the way to terminal illness.

There are a bunch, millions of bugs on differents implentations, 3 years ago i tried to just only develop on j2me because of my experience on j2se, i noticed bugs on nokia implementations, some months ago i have been at campus party 2007 in spain, and participating in a 72 hours j2me development contest, well, i must say that at least 60% of that time was spent in differences between Nokia N70 and Nokia 5300 - even in the same brand, in same year models, implementation is different...

Notice this bug on Nokia imp, "when phone goes into turn-off-backlight mode, there is NO way to turn it on", it has been like this since almost 3 years, so it is impossible to code a simple "no user control" application (like car GPS navigation vía Bluetooth)

[And of couse, J2SE needs the same apis as J2ME, Connection architecture , Bluetooth, Gaming]

Posted by Daniel Rodriguez Millán on October 23, 2007 at 11:31 PM PDT #

Java SE needs a Bluetooth API as well. More, it needs a networking API that isn't tied to the IP stack. In the mobile future, IP will be one of many network technologies connecting devices to the world.

Posted by guest on October 24, 2007 at 01:35 AM PDT #

Now that Apple announced a "real" SDK for the iPhone and iPod Touch for February 2008, what are the chances of seeing Java on that platform?

Posted by Winfried Maus on October 24, 2007 at 09:07 AM PDT #

I'd like to hear a comment on why Java 6 isn't in Mac OS X 10.5.

Specifically, is Steve Jobs excluding Java support to pressure Sun into a cheaper buyout offer?

Does Apple's recent about-face on Java reflect Steve Job's famous ego in dealing with other companies?

The only way I can rationalize Apple's behavior is to believe Steve is trying to give Sun the shaft in an effort to lower Sun's bargaining position.

Clearly Apple and Sun continue to have a highly complementary product line-up that would make a buyout by Apple an obvious move. ...

Posted by Ben on October 27, 2007 at 11:59 AM PDT #

At first I was also extremely annoyed by the lack of Java 6 in Leopard.

However, the version of Java 5 that comes with Leopard shows improved performance over Java 5 on Tiger, and basically, when you are not on Windows, the better performance of Java 6 is its strongest selling point. Other than that, is the difference between the two versions -that- big?

Where I work, they are currently rolling out an Oracle Initiator/J based software, and Initiator/J is Java 1.3... That puts the "where's Java 6" fuzz in a slightly different light for me, and the truth actually is that only few users out there are on Java 6 already. So does it really matter that we still don't have it on OS X? Probably not.

What matters, however, is Apple's non-information policy. Can you trust a company that does not communicate with its developer base? Would you bet your business on such a company?

On the other hand, what alternatives are there? I moved away from Windows two years ago. GNU/Linux and Solaris are no desktop operating systems - at least not for me and my needs.

At the end of the day, it still is either Windows or OS X for me. And going back to Windows and PCs...? No, not really.

Posted by Winfried Maus on October 28, 2007 at 03:55 AM PDT #

In my experience, the main problems with JavaME for app development and deployment:

- the signing process is expensive and tedious and, even after going through the hassle, the user must explicitly grant some permissions

- java apps do not have jni-like access to the device, so I can't take advantage of a particular device's special features

- lcdui is antiquated and I would rather not have to rely on 3rd party windowing/menuing

- the jvm startup on takes toooo looong

In my opinion, the carrier networks and javame implementors are mostly to blame for this mess.

I think Flash Lite 2.1+ and initiatives like pys60 have the potential for displacing javame as the preferred way to write apps for mobile devices.

Posted by MikeC on October 28, 2007 at 11:38 PM PDT #

Post a Comment:
Comments are closed for this entry.



« July 2016