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."

Comments

I think you mean...

[MrNonchalant]

Write once, debug everywhere.

Zing!

Re:I think you mean...

[bladesjester]

I've said it before, and it should be said again. Most of the problems people have with java not being portable are due to stupid mistakes and shortcuts by the programmer.

The two most common problems (which should not happen) are use of non-core packages and hard coding of file seperator characters in pathnames instead of using File.seperator

Sun even takes pains to point these things out, but a lot of people don't listen, so those of use who write useable, portable code get to hear "java is teh suxor" too often.

Re:I think you mean...

[oncebitter]

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".

Re:I think you mean...

[BigLinuxGuy]

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.....

Good luck

[bunions]

If there's an area that really needs compile-once, run-anywhere it's cell phones. Last time I looked at MIDP it was really hobbled by catering to the lowest common denominator - IIRC, all you had for user interaction was up, down, select and keypad entry. Hopefully there's some progress on that front.

Wake me up when Verizon Wireless joins in

[feijai]

Until then, I'll still be stuck with intentionally Java-broken phones. Unity my butt.

Re:Wake me up when Verizon Wireless joins in

[Anonymous Coward]

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.

MIDP, Cell Phone Vendors, and Carriers

[deanj]

I've been to many JavaOne conferences. I've heard the cry to develop for MIDP.

I listened to the vendors and Sun, and all the "There's lots of opportunity".

You know what? That was complete bullshit.

The hurdles a small development company (3 or 4 guys, or smaller) has to go through to get an app developed is one thing. That can be handled. Code is code. Even with bugs in some of their phones (Hi there, Samsung), issues can be worked around.

The real problem is dealing with the phone vendors and the carriers. The vendors less so than the carriers. They charge an enormous amount of money to do "compliance" testing, and then, IF you're lucky, you'll get picked to be put on their download lists. And then they take a massive cut of the purchase price.

Like I said, this is IF you're lucky. The last time we looked into it, small publishers had to get accepted by bigger publishers just to get your app noticed.

This is yet another instance of the unbridled greed that cell phone carriers have in this market; Handhelds, such as Treo (Palm & now, Windows), don't have the crap to deal with that Java apps do.

Stick with Palm/Windows unless you can get picked up by a big publishers (JAMDAT, etc). The headaches with working with Sprint's "support" (ha!) isn't worth it.

Re:the "write-once, run everywhere" motto is true

[ranjix]

probably I didn't stress enough in my post:

since I started writing in Java, I started running everywhere...

now that I repeat it, it doesn't sound funny anymore. forget it

Motorola/Nextel was good for J2ME

[FerretFrottage]

I've done some J2ME development and it can be chore. Phone display sizes/interfaces (MIDP stuff) aside, there are a couple of other things that make the development environment less than ideal.
--Most phone still on supoprt CLDC 1.0 while CLDC 1.1 has been available for a couple of years (major benefit of 1.1 is floating point support)
--Mobile carrier support for development

Nextel (now Sprint) was the best IMHO WRT J2ME with their iDen program. Motorola made development documentation easily available (Nokia does too IIRC) and even provided documentation and examples to their java location APIs. I must say it was pretty cool to develop a J2ME geocaching app that could work almost as well as a dedicated GPS unit (with the phone you don't have a much accuracy as a dedicated unit, but I was still able to find the caches). The bonus was that the phone app could then send a query to the geocache site with your current location and then retrieve nearby locations; I used this a few times while on vacation.

Yeah, it was fun, but since J2ME location APIs (if available) are vendor sepcific (no JSR was even in the works at the time when I did this), it wasn't just write once debug everywhere, it was write everywhere, debug everywhere. Sure factory patterns and the like make development easier, but with J2ME you want your code to be as small as possible and sometimes what might be the "best" OO approach may not be practical on a J2ME device.

Re:Motorola/Nextel was good for J2ME

[Amon Re]

JSR 179 is the standard for J2ME location services. http://www.jcp.org/en/jsr/detail?id=179