Slashdot Mirror
Motorola Seeks Mobile Unity at JavaOne
Mike Barton writes "InfoWorld's Paul Krill reports that Motorola and Eclipse will unveil open source mobile initiatives at the JavaOne conference this week to broaden Java's mobile and software ecosystem. From the article: 'Motorola also will develop under an open process a references implementation and compliance test for Motorola-driven Java Specification Requests, such as the Mobile Information Device Profiles (MIDP) 3.0 specification.' Motorola's goal is "write-once, run everywhere" implementation capabilities."
Depending on your phone, they're fairly easy to crack and replace the firmware with functional variants (I have a working E815 with a hello world java app on it). And don't forget, Motorola helps them break their phones.
Tried Netbeans? Y'know, GUI builder, works for J2ME... And does MIDP GUI design too?
The issue is not the JVM/KVM but the MIDP/CLDC implementation layer in mobile phones -- they are always inconsistent and usually buggy. Great strides have been made, but "write once, run anywhere" applied to J2ME is the biggest joke in the industry, as any of the dozen engineers at my company dedicated to porting code to different J2ME devices will agree. Blame Sun's certification tests. Curiously, Motorola is one of the worst offenders.
Ironically, Qualcomm's iron-fisted control of BREW (a C-based competitor to J2ME) has resulted in much higher levels of consistency, approximating "write once run anywhere".
JSR 179 is the standard for J2ME location services. http://www.jcp.org/en/jsr/detail?id=179
Programming for the Java Standard Edition is not the same as programming for the Java Micro Edition. The JME JVM is just about as non-standard across embedded devices as it gets. Best practices in JME are to use as few classes as possible to avoid as much of the overhead inherent in the class loader. Due to these inconsistencies, one has the issue of potentially having to debug everywhere due to a non-standard platform implementation. The wireless carriers are pushing for a "standard" embedded JVM, but are years away from realizing anything from the OEMs. In the meantime, worst practices are still used to create applications (most notably building monolithic applications with no use of MVC).
JME apps are also measurably slower on embedded devices than a natively compiled binary. Not a good thing for the embedded space where the processors are not particulary powerful. The argument that "devices are getting more powerful and have more memory" is at best silly since battery life is not getting any longer (shorter in fact due to the larger screens, more powerful processors, and memory).
Other technologies, like Adobe's FlashLite, are positioned to provide a uniform presentation platform long before the issues with embedded Java will be worked out. That means that business logic layer is next and for the most part I'll take faster with fewer CPU cycles over a non-existent WORA promise. Of course, that makes it harder for developers so perhaps it will ensure that embedded space development doesn't become the same kind of commodity as "mainstream" development.
But your mileage may vary.....