For the last few years, Java has been the dominant platform on lower-end mobile phones (e.g. S40 Nokias, or Ericssons other than the P900 series). It's easy to see why: the same game can be run on any of these phones without the need to be recompiled.
The case for compile once, run anywhere died at least two years ago. Increasingly, mobile phone manufacturers are extending the capabilities of the runtime. Java applications written for one particular phone are unlikely to run on phones of a different brand. Which raises the question: Why bother doing it in Java anymore?
On a "smart phone" running Symbian, it's so blatantly obvious which applications were written in Java and which were written in Symbian's C. Does it take 30 seconds before it displays anything? Does it perform noticeably sluggishly? Do the controls not look like the native Symbian controls; skinned properly? These are exactly the same complaints desktop users have about Java applications -- only on a mobile phone, it's worse, because resources are significantly more limited.
Google recently launched the "Android" project: An "open" platform for mobile computing. Their rife is that most mobile phone operating systems don't let you get down into the guts of it and change it. Fair enough.
The language for use on Android is Java. Although they're using a custom virtual machine, therein lies the problem. Mobile devices have limited resources. A slow CPU (300Mhz if you're lucky), and limited memory. Running a virtual machine to interpret bytecodes a CPU this slow simply doesn't make sense.
All in all, I think this picture really sums it up:
Comments
While I do agree with your central thesis - "Java sucks", some thoughts:
I think it's become more "important" - would any of those shitty mobile phone games be profitable if they had to be ported to each phone architecture out there? Maybe that would be an advantage.
I don't know if this is the case, but the J2ME standard is also being enhanced for new technologies - e.g. JSR 179 adds support for the "Location API", allowing applications to portably make use of GPS receivers. Phone vendors seem to be involved in the Java "Community" Process, adding new features to it instead of proprietary vendor-specific extensions.
In light of the above, is this really true? And this applies doubly to Symbian (and note Series 1 & 2 programs can't simply run on Series 3) and whatever Blackberry uses.
As far as I can tell from here, all the non-J2ME APIs available to Java in Android are available to C++ code, too.
Some modern ARM CPUs include Jazella, an extension that can directly execute Java bytecode, but Android appears to compile Java byte code to something else before running it in their custom VM Dalvik. I don't think it's fair to assume it will be "too slow" until the actual hardware is released. And if it easily runs applications at an acceptable speed, then the "security" gains of running in a JVM could easily make this a big advantage.
Also, the picture: a) it's an emulator, b) the lack of testing and/or design leading to NullPointerExceptions would lead to segfaults in other languages.
Also, woo
Hello,
I want to know if i can run my cdc jar on android ?Namely has the android have jvm for cdc?Or can i use midlet against cdc application for my db and swing based applications?
What about midlet support of android?
Thanks in advance!