Slashdot Mirror
Five Years On, Has J2ME's Time Finally Arrived?
jg21 writes "Although he admits to having been frustrated by the slow adoption of the J2ME platform, software developer Eric Giguere believes that we're 'turning the corner.' He remembers Sun demonstrating Java running on Palm OS 'way back in 1999 when so many hoped the wireless Java revolution was just around the corner. Five years on, with notable successes such as the J2ME-enabled BlackBerry wireless handheld, that has already made a billionaire of RIM founder Mike Lazaridis, Giguere claims that, with most of the new handsets being produced supporting either JTWI or else its key component - version 2 of the Mobile Information Device Profile (MIDP) - developers finally now have a more consistent and capable platform to use for application development. Anyone wandering round this week's CES may be inclined to agree."
Not to be a troll, but what is it with all these intriguing Java products, free for downloading, that don't go too far?
- Jini
- Java 2D
- Java 3D
- Java Mail
- etc.
Is it that they are insufficient, too expensive, not completely open, or what?"Provided by the management for your protection."
You're kidding right? All the blackberrys are J2ME based and this is the fastest growing PDA out there....
since there are about several hundred devices out there, what exactly are you going to program in if you want to target a braod enough audience?
i can't believe programmers are so ignorant about mobile development! there's more than just the server you know...
HELLO????
open any teenager magazine(at least in europe) and half the adverts are for j2me games(and ringtones.. sigh.).
and practically all phones are coming with j2me now...
world was created 5 seconds before this post as it is.
Well I developed and tested J2ME applications on many different mobile phones. Performance optimizations were needed only for Sony Ericsson T series phones. Everywhere else I found the performance of the applications to be acceptable, in most cases you cannot see response time difference between J2ME application and native application of the mobile device. There are few tricks used, in order to be achieved this. (example: on some devices the JVM is loaded not on the start of the application, but when you go to the J2ME applications phone menu). Sorry when my english is bad, I'm not native english speaker.
Here's the actual working link to my guest editorial.
EricI don't think processing speed is the real issue - the real issue is trying to make a usefull application that works on 64x64 black and white and 320x240 color, with or without a keyboard, with or without TCP/IP, with or without sound, etc.
The language does a pretty good job of allowing you to write one ap to all these, but what ap could you write?
while (sig==sig) sig=!sig;
Idiot? More than likely. But in this case, it was more of a simple typo.
Wait .. you mean that J2ME isn't Java for Windows ME?
One line blog. I hear that they're called Twitters now.
Well, not necessarily. Midlets are sandboxed for good reasons -- the last thing you need is to have your phone acting like IE with pop up ads, spyware etc.
That said, if sandboxing is a problem there is always personal profile if you are working on PDAs. It is pretty much just a slimmed down J2SE with pretty much all the access to the hardware you'd need, with AWT, which may not be your favorite toolkit, but is sufficient for PDA work. IBM's Websphere has SWT on PocketPC, which is clean and nice.
Even sandboxed, there are lots of useful applications that could be written other than the more or less pathetic games that seem to dominate this space.
I see two main issues with J2ME as a whole. The first issue is that performance is so limited. The ones I've used are OK once JIT has had a chance to do its magic, but getting the application off the dime on startup can be pretty painful. A lot of applications for mobile development require responsiveness. The Pizza delivery guy is going to freak if his delivery tracking program takes twenty seconds to launch while he's sitting on the doorstep.
You could locate a lot of your business logic off the phone, but in that case you might as well consider going browser based.
The second issue is that not many people have experience developing for such a constrained user interface. You just can't try to shrink down the same old things you do on a VGA resolution monitor to a PDA or worse yet a phone. There's a shift in style you have to make that takes some practice.
Actually, trying to do some non-trivial stuff on a PDA is good design exercise, and changes the way you look at other kinds of user interfaces.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
I tried to develop some applications for my cellphone using J2ME, unfortunately when I did try to do it I found several limitations. Primarily because it does not take advantage of features provided by the device.
Although for the most part J2ME is meant to be as portable for as many devices as possible, it would've been nice to provide facilities to manipulate common PDA features such as: address book, calendar and todo list. I was surprised I couldn't even touch those when I was doing MIDP development before.
J2ME is more about connectivity to remote systems which may be good for business applications, its also very expensive to deploy because of the costs of cell phone air time. Still its not too bad.
With J2ME and all the drawing facilities, another common application type you can build with this are games. I've seen a few java based games and they're not too too bad.
I think it would gain ground if Symbian releases a library that provides direct access to its core facilities such as changing the screen saver, the background images, and replacing the application menu. Mind you there are applications that do these already, though you have to pay for it for something so simple, although setting up the C development environment for Symbian is difficult too.
Archie - CIO-for-hire
J2ME MIDP 1.0 fragmented the embedded market, takes too many precious resources, and is an underperformer.
... Which are handset-specific. SymbianOS handsets don't account for a large piece of the market at all. Java works because you can write an app and port it to 90% of handsets.
With respect, I don't think it was the MIDP1.0 that fragmented the market (after all, it was a specification) - just the fact that the different handset manufacturers implementations of MIDP1.0 were different is what produced dissimilar results.
If anything, MIDP1.0 united the market (nowadays, nearly all handsets come with a MIDP implementation) because it had a broad enough scope and was small enough that handset manufacturers would include it with little hassle - remember that in the world of handset manufacturers, development support is way down the list of priorities.
Re: Resources and performance, that's down to the manufacturers implementation. You can't just make a sweeping statement like that and expect it to be the same for all handsets!
J2ME MIDP 2.0 was better in terms of features, but little else.
The features that were implemented in MIDP2.0 covered pretty much all the gaps that MIDP1.0 highlighted. The great thing about it was that it was all the right gaps without bloating it!
If J2ME MIDP is so wonderful, why do the cellphone manufacturers write their applications in C++ (especially for the Symbian OS)? Perhaps it's because they know those dirty little secrets?
Put down the SUN cup with MicroJava and get into rehab.
I don't really evangelise about languages, or have my favourites. It's a case of using the best tool for the job, which IMHO is java. Your whole argument seems to be based on performance alone - while that is fair and good for performance-critical apps, java performance isn't that bad, and performance is only an issue for certain applications.
Re: get into rehab. Why resort to flamebait? It's only a choice of language.
---
"An eye for an eye leaves the whole world blind" - Gandhi