This post originated from an RSS feed registered with Java Buzz
by Russell Beattie.
Original Post: Lack of MIDP Quality Control And Standarization Sucks
Feed Title: Russell Beattie Notebook
Feed URL: http://www.russellbeattie.com/notebook/rss.jsp?q=java,code,mobile
Feed Description: My online notebook with thoughts, comments, links and more.
More on J2ME: Steve at Burning Door reviews the first couple of MIDP 2.0 phones and doesn't get much joy. I'm with him. We ran into this very problem below just yesterday at work and it *sucked*:
... the list of known issues in the nokia 6600 MIDP implementation are atrocious. Nokia uses SUN's Monty VM in their implementation so some of these things are perhaps not their fault, but it definitely shows a lack of testing and a rush to market. Understood but not totally forgiveable in this market. I don't know if the P900 uses this VM or another VM.
There are other things that definitely are their fault from a lack of testing. A prime example is not implementing the MIDlet.platformRequest() method which is new and has prevented my feed reader from running on this phone. Calling this method with the right parameters is supposed to either make a phone call or launch the default browser. It currently crashes the 6600 - and unless Nokia provides a way for users to update their own firmware, it's going to leave a whole lot of phones that don't really support MIDP2.0. Couldn't they have gotten a programmer to pull an all-nighter and gotten this right? The sun was probably up all night anyway in Finland since this was released in the Summer.
Not supporting the platformRequest was a real bummer. But the worst bit is the way the app that uses the call fails: It crashes! Urgh! Try the API call the first time and it doesn't do anything. Click again, and it kills the app "App. closed MontyThread - 6 KERN-EXEC 3!" Are you kidding me?!?! I've run into this type of crappy J2ME implementation before on the Nokia 3650 with the sockets problems I had, but that was using an "unsupported feature." This is a MIDP 2.0 requirement and it *crashes* the app. No errors, no recovery.
I don't get it, I really don't. *None* of the MIDP games I have from my 7650/3650 work properly on the 6600. WHY?? And now we're trying to do development using the new spec which is supposed to help with many of these problems, and the phone dies. That sucks.
And the reality is this same game is played per phone out there. That's insane. It's nuts enough to "write once, debug everywhere" when you're talking about PC platforms, of which there's just a handful. Now we're talking about *hundreds* of Java phones. And this type of behavior is classic - where the app crashes, or just doesn't respond to an API call, rather than gracefully die or error out. So you can't put a few lines of code in your app to test for phone versions or gracefully back out of problems. No, you've to got write and test for each phone (or really series of phones, since the 7650/3650/N-Gage are about the same) and deliver essentially a different app. Yes, there's a ton of code reuse, however there's also massive problems with branching your codebase and keeping track of different updates, bug fixes etc.
Anyways, I probably wouldn't be sooo annoyed if that one feature wasn't so useful (shelling out to a WAP Browser from within your J2ME app), but when they screw up so badly on one of the most useful new features of MIDP 2.0, you just know that the whole J2ME process is just broken.
That PDF of issues from Nokia is an embarassment to them and to Sun. This is Nokia's *flagship* phone, and its Java support blows chunks. How much more of sign do you need?
Previous Topic
