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

Comments

Java Orphans?

[4of12]

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?

Re:Java Orphans?

[Anonymous Coward]

of the 4 you mentioned, only JINI is, as far as I know, not being extensively used...The others are APIs that are incorporated into J2EE or J2SE products to provide functionality. For example, JavaMail is the API that's used when you want to send and manipulate email.

Re:Java Orphans?

[RAMMS EIN]

Well, Java is just not a particularly good language. No amount of add-ons and libraries is going to change that. However, there is hope. The language is slowly picking up flexibility, which will get rid of one major reason to avoid Java.

Re:Java Orphans?

[IndigoSkies]

Java is just not a particularly good language

Why don't you tell us what you think is a good language and/or what makes Java so bad. Compare and contrast them if you want people to get any value out of your statement.

Re:Java Orphans?

[curious.corn]

excuse me, I feel the urge to chime before going back to a long coding session on Eclipse... oh! you're soo right... what a horrible language, you can't really do anything useful with it... I'd better get back to speed on my PHP skillz.

Re:Java Orphans?

[RAMMS EIN]

The defect of Java I feel most is its lack of flexibility. There's one paradigm and that's what you have to use. There are no macros, and the recently introduced generics are but a poor substitute.

On top of that, Java is very verbose. Type declarations, wrapping everything in classes, casts, mandatory exception handlers, etc. all stand in the way of rapid development.

The vanilla runtime environment is a huge download, and the development environment is even worse. The VM takes up a lot of memory, and the startup time basically rules out efficient little programs (think Unix commands). AFAIK, neither the runtime nor the development environment come with a run-time debugger. There's no such thing as incremental compilation or a read-eval-print loop.

Some things exist in Java, but are a pain to use. For example, anonymous methods (useful, for example, for mapping over a sequence), need to be wrapped in classes. Iterators exist, but are clumsy. Containers like List and Vector store Objects, which is practically never what you really want.

You asked what languages I do like? Lisp and Ruby, mostly. If you compare them to Java, you will indeed find that they are a lot ligther, but also more elegant and flexible. They may not have a library for every Java library out there, but I'm pretty sure these could be implemented if needed; what's more, I'm willing to bet the implementations would be smaller.

Re:Java Orphans?

[tigeba]

"The defect of Java I feel most is its lack of flexibility. There's one paradigm and that's what you have to use. There are no macros, and the recently introduced generics are but a poor substitute."

I agree that java is somewhat inflexible, but macros? come on! The whole point of eliminating macros is to eliminate confusion and reduce complexity.

"The vanilla runtime environment is a huge download, and the development environment is even worse. The VM takes up a lot of memory, and the startup time basically rules out efficient little programs (think Unix commands). AFAIK, neither the runtime nor the development environment come with a run-time debugger. There's no such thing as incremental compilation or a read-eval-print loop."

I just downloaded the Ruby-all-in-one enviornemt for windows and it clocked in at around 14 meg, so its hardly "light". I suspect that most of this is various cygwin crud needed to get it to work, but the point remains. Since this is supposed to be a thread about J2ME, I would point out that I have a JVM running on arm-xscale that clocks in at about 500K (i am lazy and it is statically linked) + whatever libs I decide to include. If you can convince people to put Ruby or Lisp on a phone, more power to ya :)

I agree that Java is probably not the best enviornment for what would essentially be command line utilites due to VM overhead (at least the Sun VM anyway).

I'm not sure when you last used Java, but it has come with a debugger for ages, check out "jdb" In fact it has had support for remote debugging and profiling of JVM's for quite some time.

AFAIK you can't do a read-eval-print loop in Ruby either, but somehow it is more elegant? (feel free to prove me wrong)

"Some things exist in Java, but are a pain to use. For example, anonymous methods (useful, for example, for mapping over a sequence), need to be wrapped in classes. Iterators exist, but are clumsy. Containers like List and Vector store Objects, which is practically never what you really want."

If you dont like Iterators, there is a simple foreach syntax

for(int i: ints)
doSomething(i);

Not sure what the beef with the container classes is, but they autobox primitives for you if that is what you need. If your concern is the overhead of the boxing, well then perhaps you should be writing in C.

Re:Java Orphans?

[Anonymous Coward]

The defect of Java I feel most is its lack of flexibility. There's one paradigm and that's what you have to use.

That's your personal opinion. Many other people feel different.

There are no macros, and the recently introduced generics are but a poor substitute. On top of that, Java is very verbose. Type declarations, wrapping everything in classes, casts, mandatory exception handlers, etc. all stand in the way of rapid development.

I don't know about you but for me these are all (maybe except sub-par generics) strengths of Java and they make my development faster as they help me keep code clean, well-structured and provides very informative errors both at compile and run time.

The vanilla runtime environment is a huge download, and the development environment is even worse.

Hard to disagree here. Standard library is too big.

The VM takes up a lot of memory, and the startup time basically rules out efficient little programs (think Unix commands).

That's not true for at least more than a year now. Basically since 1.4.2 JVM startup is very good and only improved with version 5.0. Also, free JVMs like Kaffe start in a fraction of second.

AFAIK, neither the runtime nor the development environment come with a run-time debugger. There's no such thing as incremental compilation or a read-eval-print loop.

Sun's JVM provides very good interface for runtime debugging and profiling. Using it standalone tools and IDEs such as Eclipse provide excellent debugger and profiler. Incremental compilation (Eclipse, jikes) is so fast you won't even notice it in all cases where you don't make project-wide changes. Not sure what you mean by 'read-eval-print loop'

Some things exist in Java, but are a pain to use. For example, anonymous methods (useful, for example, for mapping over a sequence), need to be wrapped in classes.

That's called consistency and object-orientation and adds to a clean language

Iterators exist, but are clumsy. Containers like List and Vector store Objects, which is practically never what you really want.

Agreed.

You asked what languages I do like? Lisp and Ruby, mostly. If you compare them to Java, you will indeed find that they are a lot ligther, but also more elegant and flexible.

Then why do you come trolling about real or perceived weaknesses of other languages? It's like others would be visiting forums and articles about whatever language is disliked by that person and post 'I don't like it, boooo hooo' comments. You prefer other languages? Fine, good for you, move on.

They may not have a library for every Java library out there, but I'm pretty sure these could be implemented if needed; what's more, I'm willing to bet the implementations would be smaller.

That's not very wise argument and you know it.

Re:Java Orphans?

[alw53]

That's right, didn't your mother ever tell you "If you can't say something nice, don't say anything at all"? You have hurt Java's feelings, now apologize!

Re:Java Orphans?

[RAMMS EIN]

Thanks for your comments.

``AFAIK you can't do a read-eval-print loop in Ruby either, but somehow it is more elegant? (feel free to prove me wrong)''

It's called irb.

``Not sure what the beef with the container classes is''

I meant that, if you wanted to iterate over a sequence of, say, Person objects, you would do:

# Ruby
# people is your array of Person objects
people.each { |x|
# do something with x
}

// Java
// people is a Vector
for(Iterator it = people.iterator(); it.hasNext(); Person x = (Person) it.next()) {
// do something with x
}

But now I see that, in Java 5, you can say

// Java 1.5
// people is a Vector<Person>
for(Person x: people) {
// do something with x
}

This is a great improvement. Thanks for the wake-up call!

Re:Java Orphans?

[dkf]

// Java
// people is a Vector
for(Iterator it = people.iterator(); it.hasNext(); Person x = (Person) it.next()) {
// do something with x
}

Actually it was even messier than that since you had to put the code to get the next element inside the loop and not as the "next" clause. All in all, it was a common piece of code that was easy to make stupid mistakes in, and so the new for syntax is a great improvement, allowing Java programmers to take advantage of iteration over collection types in a way similar to Ruby (and Perl, Python, Tcl, and probably many others) has done for ages.

Re:Java Orphans?

[mooZENDog]

Most companies have a preferred language. If you're developing in java, then the products you mention will just be more reasons of why you *can* do what you want using java. It's flexible like that.

Re:Java Orphans?

[sporty]

They stay as sperate products unless they pick up enough steam.

Java2D got integrated as anyone who uses swing will want it. I think jini is included, but i'm not sure. Java mail, i'm sure will be in a j2ee implementation soon enough.

Instead of flat out bloating the API by adding stuff, ala php, they incubate it out in the wild.

Re:Java Orphans?

[cortana]

So basically, you dislike Java because it is not Lisp? :)

Remember, Java is an excellent language to use on your project, because it allows a PHB to hire hundreds of cheap, poor programmers, as a commodity. Java's structure reduces the difference between how different people/teams write code, so that new developers can be integrated into a development team faster, spending less time learning the ropes of a particular project.

Java is a good tool to allow poor programmers to write reasonable code. :)

Re:Java Orphans?

[k98sven]

Well, Java 2D has been part of the Standard Edition since version 1.2, so I'm not sure what you're on about there.

As for the rest.. The strategy is perfectly clear. Sun makes a bunch of java add-ons in the com.sun.* heirarchy and releases them. If they catch on, they eventually get integrated into Standard Edition.

Swing, Sound and ImageIO for instance.

Re:Java Orphans?

[Anonymous Coward]

So your primary complaint is that... Java is strongly typed. That's it?

Now that's a reasonable complaint. Java is verbose indeed, and it MOSTLY comes from having to cast the gazeebos out of things due to the typing constraints. I hate that too. And I too hate having to wrap things in classes in a clumsy fashion mostly because of a lack of pretty Lisp macros (yes, I too am a big Lisp fan). There's a lot to say for the elegance of a weak-typed, macro-oriented language no doubt.

But much as I love Lisp, it's not even an option for the vast majority of stuff I want to do. Let's get the big one out of the way. No free, open version of Lisp has standard, cross-platform, free graphical interface facilities. None. Holy crap. And the commercial ones (Xanalys, Allegro, whatnot) have sortof sandbox toolkits at best. We've been using GUIs for what, 20 years now? And don't throw that CLIM crap at me: we both know what a piece of garbage it is.

Lisp has no standard facilities for multithreading. HOLY FREAKING CRAP. We've been doing multithreading for 35 years. Lisp has no internationalization facilities. No weak references and soft references. No standard native code facility. No standardization on efficiency declarations -- I love all the +foo gunk that you see in modern Lisp systems. Wasn't Lisp supposed to enable cross-platform code? I guess not in reality.

And then there are the libraries. Unlike Lisp, Java has standard toolkits for XML, cryptography, 2D graphics, typography, database access, printing, big decimals, networking, the list goes on and on.

And this is important: at present I cannot write portable Lisp code which is faster than plain Java code. And don't get me started on the speed-demons that are Ruby and Python :-) One reason I write in Java instead of Python is that in my experience, my programs run almost exactly 10 times the speed.

So sure, Java's not nearly as pretty as Lisp. It's not as elegant by far. Doing closures is a pain and it has no macros. But it has so many modern language features that Lisp is missing that I'm willing to overlook that by quite a bit. As a famous professor once said, Java is the first production language that computer scientists aren't horribly embarrassed at. That's what I'm looking for. A production language. Something I can get work done in and hasn''t been frozen in time like Lisp. But something which isn't grotesque like Perl or C++, horrifically slow like Python or Ruby. Also something which I can run on Macs, Linux, and Windows. And Palm pilots. And Newtons. And BSD. And WinCE. And my blackberry. There's a lot to be said for that.

Re:Java Orphans?

[Anonymous Coward]

The VM takes up a lot of memory and the startup time basically rules out efficient little programs (think Unix commands).

I thought you were describing differences between Java and Lisp :=)

AFAIK, neither the runtime nor the development environment come with a run-time debugger. There's no such thing as incremental compilation or a read-eval-print loop.

The development environment comes with a debugger. But more importantly, any decent Java IDE (even trivial educational ones like jGRASP, all the way up to big stuff like Eclipse) has a good debugger facility.

It's worth mentioning here that Lisp's debugging environments are among the very worst I have ever had the misfortune to use. I'm not talking about free gunk like CMUCL. I'm talking supposedly high-quality, commercial systems like Lispworks or Allegro. Truly awful compared to even xxgdb. Dark ages.

As to a topline read-eval-print loop, have I got a treat for you: BeanShell is exactly what you want. A Lisp-like command-line for Java. Fan-tastic! Oh, and it's embedded in most modern IDEs to.

Anyone? Anyone?

[AntsInMyPants]

A slashdot story on the front page this long with no replies? Maybe the real question is, Does any one care if J2EE is ready for primetime.

Re:Anyone? Anyone?

[Anonymous Coward]

J2EE? Are you actually an idiot or what?

J2EE is Java for servers...we're talking about J2ME (Java 2 MicroEdition), which is for mobile devices and is the de facto standard for programming devices like cellphones, blackberrys, smart cards, etc.

Re:Anyone? Anyone?

[Heftklammerdosierer!]

I think the real question is, "people still use Java?"

Re:Anyone? Anyone?

[Anonymous Coward]

RTFA article and you'd know why.
Or better said, *try* to RTFA and you'd know why.

Re:Anyone? Anyone?

[AntsInMyPants]

Idiot? More than likely. But in this case, it was more of a simple typo.

Re:Anyone? Anyone?

[AntsInMyPants]

The comment was about the lack of comments on Slashdot not any commentary on the post. On a tech website where front page stories receive hundreds of comments in moments, I found it unusual that this had none. If you had RTFC, you'd know that.

Re:Anyone? Anyone?

[aled]

did you mean J2ME? or you are confusing J2EE with J2ME?

Re:Anyone? Anyone?

[BigLinuxGuy]

Aw, come on. That's like asking if people still use Visual Basic, Object Pascal, COBOL, or Fortran. Of course they do because it's probably the only language that they know and therefore it's the correct choice for implementing all solutions because it was hard to learn and therefore any other language must be equally difficult so it can't bring any real value.

But the real question is why do the cell phone manufacturers write most of their apps in C++?

Re:Anyone? Anyone?

[m50d]

We don't care, because we've all moved past java. Spend long enough programming in Python or Ruby and Java starts to look like combining the performance of those languages with the ease of programming of C.

I still don't see the point...

[RAMMS EIN]

I still don't really see the point of J2ME. Every Java app that I have seen run on a phone or PDA has been dog slow or at least sluggish. Isn't J2ME specifically intended for these devices? If so, then why does it suck so much? If not, isn't J2ME a solution in search of a problem?

Re:I still don't see the point...

[Anonymous Coward]

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

Re:I still don't see the point...

[geo.georgi]

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.

Re:I still don't see the point...

[WhiplashII]

I 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?

Re:I still don't see the point...

[cpeterso]

I never understood why an interpreted language was a good idea for slow mobile devices. Do any J2ME JVMs do JIT compilation?

And J2ME JVMs are so broken and incompatible that JAMDAT has support something like 70 different builds of the "same" game to support different JVMs!

Re:I still don't see the point...

[Anonymous Coward]

Some devices do JIT - some newer devices will use Jazelle (ARM java op-codes).

The JVM's aren't (generally) incompatible - but things like screen size, audio capabilities, colour reproduction and supported keys tend to differ from device to device. This is why JAMDat have 70 builds - although I think you'll also find that those 70 builds include language variations.

Space permitting (don't forget 2nd gen devices only had 64K to play with) its normally possible to abstract most of the differences.

Re:I still don't see the point...

[m50d]

I don't think it is such a good idea. People just rushed to put Java on everything, because it was very PHB-friendly. And still is, unfortunately. It's an OK language but it's very overused because it's, basically, a buzzword.

...slow adoption?????

[gl4ss]

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

Re:...slow adoption?????

[gl4ss]

been for couple of years, meant to say.

J2ME is worthless

[Safety Cap]

Sorry, but running code in a Sandbox (separated from the DATA) makes it pretty much worth a pinch o' bat guano.

The alternative, of course, is Active X, but that's like sharing dirty needles.

There needs to be a happy medium where it is easy (i.e., happens automatically) to have the program get access to the OS's API, but some things are protected. Whoever can figure that one out will win a prize.

Re:J2ME is worthless

[Anonymous Coward]

Does anyone know of a real (not vaporware) on-device debug capability for a J2ME device? There was supposed to be one for the KVM I was using but it really just wasn't there at all.

Re:J2ME is worthless

[j2medev]

J2ME adoption has been tremendous. Go read Java Turns 5!. This means there is an opportunity out there to make some dough by creating J2ME-based solutions. Up to you if you want to take advantage of this opportunity...

ceo
www.j2medeveloper.com

Re:J2ME is worthless

[Spiritwalker]

With IBM's WSDD and J9, debugging on the target (PalmOS, PocketPC, etc) has always been supported.

Re:J2ME is worthless

[j2medev]

Dang it, fixing article info:
See J2ME Technology Turns 5! at http://developers.sun.com/techtopics/mobility/j2me /articles/5anniversary.html
ceo
www.j2medeveloper.com

Re:J2ME is worthless

[AndroidCat]

Wait .. you mean that J2ME isn't Java for Windows ME?

Re:J2ME is worthless

[Anonymous Coward]

It's called C++.

Re:J2ME is worthless

[Anonymous Coward]

idiot! activeX does not run in mobile devices...where do we get these script kiddies?

Re:J2ME is worthless

[aled]

Sorry, but running code in a Sandbox (separated from the DATA) makes it pretty much worth a pinch o' bat guano.

Can you present some case to your proposition or are you expecting that people take it axiomatically? I wonder why a perfectly good method for code security is not good. And for old ActiveX, Microsoft is doing pretty much the same as Java in .Net.

Re:J2ME is worthless

[hey!]

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.

Re:J2ME is worthless

[gl4ss]

there's a file access api, too, available in at least nokia 6630 to my knoweledge(and really, there's a way to store data otherwise anyhow).

so, basically, someone already won your prize. the phones offer some access to os api, leaving some inaccessible.

and i don't really get why you couldn't have data _in_ the sandbox.

but you don't really sound like you got a fucking clue about what you're talking since you've thrown in activex too, which is not really in use anywhere in the millions and millions of j2me devices travelling the streets in peoples pockets.

Re:J2ME is worthless

[Anonymous Coward]

On device debugging is a available on all Sony Ericsson devices since the t610. Released way back.

Re:J2ME is worthless

[Anonymous Coward]

Sony Ericsson phones have on device debugging in all Java phones. Thus avaliable in Z1010, K700, K500, V800, S700 etc.

Here's a working link

[Eric Giguere]

Here's the actual working link to my guest editorial.

Eric

Re:Here's a working link

[Anonymous Coward]

Eric:

You're a respected Java developer...do you actually think you'll get good discussion from a site populated by script kiddies who think PHP is the answer to everything? C'mon, when you see people comparing J2ME to ActiveX, or mistaking J2ME for J2EE, you really are in the wrong place...

Slashdot makes javalobby look like a respectable forum! ;-)

Re:Here's a working link

[Eric Giguere]

I had nothing to do with the original Slashdot story... someone else submitted that. I'm just clarifying the link.

The comments can be funny, though, like the kerfuffle that was caused earlier today by my use of "kerfuffle" in the story I did submit.

Eric
View your HTTP headers here

Re:Anyone? Anyone? - Shoulda used the Preview

[AntsInMyPants]

Damn....of course that was supposed to be "...not any commentary on the *article*."

It's dead Jim

[Anonymous Coward]

Can we just let Java die please?

Oh wait, Java is useful for something... just the other day one of my clients who was running some kind of contest sign-up form on their web site ended up getting script-spammed by some java application that a sweepstakes-fan site has been distributing. It seems people are using java to automate the process of filling out web contest forms and creating havoc across the net.

Re:It's dead Jim

[lphuberdeau]

You mean JavaScript right?

Why it won't gain ground

[trajano]

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.

Re:Why it won't gain ground

[mooZENDog]

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.

This is why MIDP2.0 is a good thing, which was the point of the article. Did you RTFA? :)

Seriously though, this is also a benefit as well as a drawback. If java had an all-encompassing API, it would likely be too big for a lot of handsets, cost too much to implement, and therefore fail as a language.

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.

Have you considered the security implications of this? Another of javas strengths in this field is its strong security focus.

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.

Most of the posts (not yours, I might add) putting java down seem to be hung up on performance. I agree with what you say about air-time, but this will be the same for any language running on a limited device. As your next paragraph states, you can get some pretty good games running on java, and I'd agree that it is a good (the best) solution for games and business apps alike.

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.

You can do this with Symbian C++ apps. However, Symbian C++ isn't available on that many handsets, and as you say, developing for Symbian C++ is difficult - the hello world program consists of four/five classes! IMHO that's a bit too heavyweight for what most developers need.

I've also just noticed your title: "Why it won't gain ground". Java comes on the vast majority of handsets. That is the main reason it won't gain ground. The reason it's got so much market share now is that it's small and light enough (while still being a reasonable, viable performer) to go on most handsets, and a reason why it has much greater market share than Symbian C++ (which is still a great language, just a bit too heavyweight IMHO).

Re:Why it won't gain ground

[Jussi K. Kojootti]

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.

Well... Those are exactly the kind of things I do not want a random application to touch. If there is good reason why a 3rd party application should get to set my phone wallpaper, I'd like to hear it. I'm not picking a fight here, I'd really like to know if you have a reason for a move that (in my book) sets way for an IE-like experience on my phone.

Re:Why it won't gain ground

[trajano]

I did use MIDP2.0 when developing, and all it had were simple forms, networking and a 2D drawing engine. From what I saw of the API it didn't have any of the contact management features I was originally looking for.

As far as security implications, we already have code signing to check for trusted sources.

As for the title, I still think it won't gain ground unless Symbian provides APIs to take advantage of the phone's capabilities, combined with Sun providing a Service Provider Interface with some common PDA features.

But then again, Swing initially was in the same sort of boat, it was meant to show portability and stuff, but not taking into consideration performance problems and general aesthetics (I still think there should be only one L&F for swing apps and that's the native OS L&F). But right now, Swing is getting pretty speedy, probably because its taking some real life developer input.

J2ME may eventually implement what real-life developers in limited devices would want. But it still has not materialized into something I can download and compile on yet.

Re:Why it won't gain ground

[trajano]

That's why we have code signing in-place with a lot of J2ME. Without those facilities, its like working in an unsigned applet on a web browser which allows you to do just plain networking and graphics.

If that's the way of the future, Sun wouldn't have developed Java Web Start to provide full access to the machine as long as it asks permission first.

J2ME?

[BigLinuxGuy]

J2ME MIDP 1.0 fragmented the embedded market, takes too many precious resources, and is an underperformer.

J2ME MIDP 2.0 was better in terms of features, but little else.

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.

Re:J2ME?

[somberlain]

By the way, is there anyone into developing J2ME games or applications? I'm working for a QA company and I have some questions regarding the mobile market...

Re:J2ME?

[Anonymous Coward]

Yup - do you have yahoo/skype id ?

Re:J2ME?

[mooZENDog]

J2ME MIDP 1.0 fragmented the embedded market, takes too many precious resources, and is an underperformer.

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?

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

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.

Re:J2ME?

[BigLinuxGuy]

J2ME MIDP 1.0 fragmented the embedded market, takes too many precious resources, and is an underperformer.

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.

Beg to differ, MIDP 1.0 had so many holes that device manufacturers were "free" to fill in the gaps for their devices in any way that they could to make it work.

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.

Not to mention that it makes the handsets buzzword compliant for marketing purposes. The sadder part is that an even better approach would be an environment that you modeled the problem in a platform independent way, then generated the platform specific code for the platforms you're interested in to ensure that the generated application was optimal for the platform rather than settle for the least commond denominator.

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!

I disagree. A poorly performing application, regardless of the platform, will not win over customers. A well performing application that makes the best use of the available resources, regardless of the platform, will take more market share. Java is the lazy way out IMHO.

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!

OK, so if I do a size comparison then you're saying that the MIDP 2.0 JVM is the same size and the MIDP 1.0 JVM. Correct? And that it takes exactly the same amount of resources or less?

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

Um, sorry to disagree but Nokia handsets are a significant part of the market, and most of them are Symbian-based (since Nokia practically owns Symbian). I'm pretty sure that you'll find Symbian on a lot of Ericsson phones too.

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.

Flamebait? Wow, I wasn't even intending to be inflammatory with my last comment, merely registering an opinion on yet another has finally arrived story. For what it's worth, Java is not the only thing that I register that comment on. If I wanted to start a flamewar I can do much better than that little piece of sarcasm. :-)

You know, the word evangelise carries a reference to a religious belief associated with "converting the unbelievers". That is the single most offensive thing that I can think of that came out of the dot-com era (and before) because I do NOT view technology as a religion. However, you hit the nail on the head. Java is just a language and there are other choices that accomplish the same ends.

Re:I GUESS SO

[BigLinuxGuy]

Interesting that the last numbers I saw had C/C++ being the #1 language in demand for actual job postings. Java was #2, closely followed by C# and PHP.

I also seem to recall that one application being distributed on 100+ million devices still only equals a single application, not 100+ million applications (must be that new math that I keep hearing about).

Funnier still that Java is still an interpreted language and that language bigots like yourself look down your nose at any other language that threatens your perception of reality.

BTW, I work in a number of languages (60+ last time I counted) to create enterprise apps and for what it's worth Java brings nothing to my table except additional overhead in terms of resources and licensing fees.

Have a nice dot-com dream..........

Ho Hum.

[turgid]

This is slashdot. "We" don't like Sun or Java here. Take a browse at -1 and see for yourself.

Who Cares??

[Nautica]

I do not care that J2ME is on its way out the door, for a one simple reason. In 5 Years do you think we are going to need a Mobile Edition of any platform, Hardware will beable to run everything we run on our desktops today.

Re:Who Cares??

[Eric Giguere]

A lot of people thought that 5 years ago, but it has yet to happen.

Eric
Why is William Shatner on my All-Bran?

Re:Slashbot Mods : On Crack or Freebase?

[Anonymous Coward]

I think it's "and I would rather be _any_where else than here today" - you deaf buffoon.

Java mail is well used

[MarkEst1973]

every time someone sends an email from a java application.

Granted, it's not the easiest API in the world and I greatly simplified all that complexity into:

Email email = new Email();
email.setRecipients(String[] recipients);
email.setSender(String sender);
email.setSubject(String subject)
email.setBody(String body)
and finally...

boolean success = email.send();

But the code implementing this is quite a bit more, required a long time debugging the mail relay issue (required authentication!), and other -- shall we say -- opportunities to learn something new.

Wow, a Troll AND an ipod sign, all in one post!

[MarkEst1973]

You are a true jackass.

Re:Wow, a Troll AND an ipod sign, all in one post!

[Anonymous Coward]

+1, Funny.

Re:Slashbot Mods : On Crack or Freebase?

[turgid]

I think it's "and I would rather be _any_where else than here today" - you deaf buffoon.

And you have never heard of irony. Anyway, it seemed somewhat apropriate for this place.

Re:I GUESS SO

[Decaff]

Funnier still that Java is still an interpreted language

Not for a long time. Almost all Java implementations translate to optimised machine code at run time.

Re:I GUESS SO

[Decaff]

Interesting that the last numbers I saw had C/C++ being the #1 language in demand for actual job postings. Java was #2, closely followed by C# and PHP

Depends where you look. What I see is Java and C/C++ about equal, C#/.Net far behind (about half the demand) and PHP hardly registering. This is in the UK, where .Net is relatively popular.

I also seem to recall that one application being distributed on 100+ million devices still only equals a single application, not 100+ million applications (must be that new math that I keep hearing about).

Ah, so those millions of Java games that were downloaded last year were all the same program.

BTW, I work in a number of languages (60+ last time I counted) to create enterprise apps and for what it's worth Java brings nothing to my table except additional overhead in terms of resources and licensing fees.

Licensing fees? What licensing fees? Use any free VM and an open source J2EE server like JBoss and there are no fees at all.

major problem: emulator consistency

[motown]

Coincidentally, I'm working on a J2ME project within my internship right now.

I've been running into this really frustrating problem of code running flawlessly on emulators, why they refuse to even start on actual devices (I only tested it with Nokia devices sofar). You click on the application, and nothing happens. You just remain in the application selection menu.

the culprit is always a certain part of the code. If I comment it out, it runs fine on the device as well. But that's what makes it so weird: apparently these are not run-time errors. The application containing the "bug" doesn't even start on the devices, let alone throw any exceptions or error messages. This makes it so incredibly painful to debug.

I really can't imagine how one could do any serious development if the emulator on one's development machine isn't 100% compatible (or at least as close to 100% compatible as possible) to the real thing.

If any other J2ME developers (more experienced than I) could shed some light on this, it would be much appreciated.

Re:major problem: emulator consistency

[Eric Giguere]

I really can't imagine how one could do any serious development if the emulator on one's development machine isn't 100% compatible (or at least as close to 100% compatible as possible) to the real thing.

Trust me, this is not an uncommon situation in mobile/handheld programming -- it's not unique to J2ME. Hard to say what exactly is the cause of your problem without seeing any code. What does the code look like?

Eric
Eric's J2ME Pages

Re:major problem: emulator consistency

[motown]

Well, before I actually place any code snippets here (it might be contractually problematic), I could describe it briefly.

I wrote a function (part of a MIDlet) that parses an XML file using the KXML2 library.

In a separate MIDlet, I had tested this code with a simple form, showing the output. That worked, both on the emulator and on my device (my trusty Nokia 6600).

Then I tried to use this code in my main MIDlet. I tried launching this function from a thread, which itself would be launched from within a CommandAction input event handler. the reason why I launched the XML parsing code from a thread, because I wanted to show an animating icon during the parsing.

That triggered the problem. So first I thought that it was possibly something related to IO within a separate thread. So I changed the code temporarily (for testing purposes), so that the XML parser would be directly launched by the CommandAction handler, without using a separate thread. This would be hanging the UI while parsing the XML code, but I was just doing this for testing purposes.

It didn't work either. When I comment out the function call (calling the XML Parsing function), all works fine, regardless if the function was called directly from the CommandAction, or from a separate thread launched from the CommandAction.

The question is: why don't I just get a run-time error as soon as the function call is reached? Why won't the MIDlet run AT ALL on the device unless I comment out the function call?

Really weird.

Oh, by the way: it doesn't seem to make any difference wether the XML is parsed from a web page or from an internal XML file within the JAR. The problem occurs eitherway (and the code also functioned flawlessly eitherway when I tested it earlier on the aforementioned simple testing MIDlet).

If you still need more information, let me know.

And thank you for your help.

Re:major problem: emulator consistency

[Eric Giguere]

When a J2ME application won't even start, it usually indicates some kind of verification error. This will often happen if a required class is missing. Are you included all the kXML2 class files in your MIDlet suite? Don't forget that you need the pull parser classes as well. I always just put the source for these right into my projects, they're so small it's the simplest solution.

Eric

Re:major problem: emulator consistency

[motown]

Hey, this is odd: the MIDlet started working om my phone after I had removed the Bouncy Castle midp_classes.zip from the Java build path!

But the Bouncy Castle classes don't give any problems until I use any code that employs KXML2.

I assume that the reason why it only goes wrong why I actually include the function call is because the obfuscator removes the entire XML parser code when it sees that the function is never called.

However, midp_classes.zip continues to stop de MIDlet from running, regardless wether I actually import something from Bouncy Castle or not.

Did you have any problems with combining KXML2 and Bouncy Castle in your MIDlets?

If I'm not able to combine these two fine libraries, then how can I possibly implement a secure solution compatible with all MIDP 1.0 phones (many of which don't support SSL)? :(

I will most likely require both libraries for my project.

I really hope that any of this will make sense to you. ;)

Re:major problem: emulator consistency

[Eric Giguere]

I've had problems with Bouncy Castle, yes, and again it was simpler to extract the classes I needed from the Bouncy Castle library and include them directly. I'd do that. I don't remember what it was exactly, but it was easier to just package what I needed directly with the app.

For those who are confused: Bouncy Castle refers to an open source Java cryptography library developed by the Legion of the Bouncy Castle. (Dumb name, but good code. Better than the reverse!)

Eric

Re:major problem: emulator consistency

[motown]

Hmmm... I assume the classes are sufficiently independent from one another? In that case, there might indeed be hope yet.

At least I can continue working on my project now. The encryption part would have been of later concern anyway.

I have one different question for you, though:

If I have to retrieve data from several url's (PNG images, XML data, etc), then how could I implement that in such a way that the user will only have to click through a single "okay to access the internet?" confirmation dialog, instead of having to go to a whole load of them?

Whatever your answer: thank you for your help and your swift responses. It is much appreciated! Is there any J2ME forum you could recommend, by the way?

Re:major problem: emulator consistency

[Eric Giguere]

Hmmm... I assume the classes are sufficiently independent from one another? In that case, there might indeed be hope yet.

I was able to extract the encryption classes I needed. See my tech tip Data Encryption for J2ME Profiles for details.

how could I implement that in such a way that the user will only have to click through a single "okay to access the internet?" confirmation dialog

This depends on the device, but in general with MIDP 2.0 you can use the permissions mechanism to basically have the user prompted only once instead of each time. See Understanding MIDP 2.0's Security Architecture.

Is there any J2ME forum you could recommend, by the way?

The hardcore J2ME types hang around on the KVM-INTEREST list run by Sun. See J2ME Mailing Lists.

Eric

Re:I GUESS SO

[BigLinuxGuy]

Ah, so those millions of Java games that were downloaded last year were all the same program.

Hmm, I'll put hard money on the table that there aren't "millions" of Java games. How about you?

Licensing fees? What licensing fees? Use any free VM and an open source J2EE server like JBoss and there are no fees at all.

Hmm, from your comment you must not work on really large enterprise systems. JBoss is great for small-to-medium sized systems, but I'm betting there's a reason that WebLogic is at the top of the heap.

Keep trying though, you'll no doubt find a way to rationalize a way around my comments. :-)

Re:I GUESS SO

[BigLinuxGuy]

Not for a long time. Almost all Java implementations translate to optimised machine code at run time.

Oh, so then I don't need to invoke the JVM with:

java .........

Still looks like semi-interpreted code to me, just cuts out part of the parsing/translation work. Try again.

Re:I GUESS SO

[Decaff]

Hmm, I'll put hard money on the table that there aren't "millions" of Java games. How about you?

I would agree, but that was not what you were arguing, was it? You were implying that millions of downloads had no connection with the number of different applications. If you had actually researched the market, you would know that there are thousands of applications.

Hmm, from your comment you must not work on really large enterprise systems. JBoss is great for small-to-medium sized systems, but I'm betting there's a reason that WebLogic is at the top of the heap.

This is true, but almost ANY large application server for ANY language on ANY system will require licencing. It is not specific to Java, as you implied. If you want to write complex middleware (and not just PHP/JSP pages) you will need such a server.

Re:I GUESS SO

[Decaff]

Not for a long time. Almost all Java implementations translate to optimised machine code at run time.

Oh, so then I don't need to invoke the JVM with:

java .........

Why is this relevant? You do understand the phrase 'at RUN time'?

Still looks like semi-interpreted code to me, just cuts out part of the parsing/translation work. Try again.

You try again. You did not say 'semi-interpreted' (whatever that means), you said 'interpreted'.

Java translation to (very optimised) machine code on almost all VMs is a simple fact:

From the documentation of Sun's Java:

"The server VM contains an advanced adaptive compiler that supports many of the same types of optimizations performed by optimizing C++ compilers, as well as some optimizations that can't be done by traditional compilers, such as aggressive inlining across virtual method invocations."

And IBM's Java:

" the Java Just-In-Time Compiler, which allows much faster execution by compiling bytecodes into native machine code on the fly. Our JIT compiler is used on almost all Java platforms of IBM, ranging from network computers (NC) to mainframes."

Hewlett-Packard's Java:

"The HP-UX Just-In-Time compiler for Java (JIT) included with the HP-UX Developer's Kit for Java automatically and efficiently converts bytecode to native machine instructions at runtime."

I hope this clears things up.

Re:I GUESS SO

[BigLinuxGuy]

Hmm, I'll put hard money on the table that there aren't "millions" of Java games. How about you?

I would agree, but that was not what you were arguing, was it? You were implying that millions of downloads had no connection with the number of different applications. If you had actually researched the market, you would know that there are thousands of applications.

No, my comment was meant to point out that millions of downloads (of anything) doesn't equate to millions of applications. Ergo sum, I remain unimpressed by the use of statistics as a spin mechanism to categorically state that "anything" has arrived or has become the "dominant force" in development.

Hmm, from your comment you must not work on really large enterprise systems. JBoss is great for small-to-medium sized systems, but I'm betting there's a reason that WebLogic is at the top of the heap.

This is true, but almost ANY large application server for ANY language on ANY system will require licencing. It is not specific to Java, as you implied. If you want to write complex middleware (and not just PHP/JSP pages) you will need such a server.

You've missed my point completely. BTW, I am not in the habit of hiding my real thoughts behind subtle innuendos. If I had MEANT to say that the licensing issue was Java-specific, I would have said so. Please refrain from putting words in my mouth. My point was to comment that JBoss is not suitable for most large enterprise application needs and those needs require a commercial, licensable Java App server such as WebLogic.

Re:I GUESS SO

[BigLinuxGuy]

Let's agree that you prefer Java and that I don't. That seems to be the only point that is coming out of this thread.

I have yet to be associated with a project written in Java where we didn't have to rewrite in another language (C or C++, usually) to fulfill the system requirements (those projects range from embedded systems to large enterprise systems).

I'm happy for you (and all the reat) that Java does what you need.

Re:I GUESS SO

[Decaff]

You've missed my point completely. BTW, I am not in the habit of hiding my real thoughts behind subtle innuendos. If I had MEANT to say that the licensing issue was Java-specific, I would have said so. Please refrain from putting words in my mouth. My point was to comment that JBoss is not suitable for most large enterprise application needs and those needs require a commercial, licensable Java App server such as WebLogic.

In your original comment you said that 'Java brings nothing to my table except additional overhead in terms of resources and licensing fees.' This implies that Java has a specific issue regarding licencing over and above other languages - that is, it is specifically more expensive or tricky to license.

Re:I GUESS SO

[Decaff]

I have yet to be associated with a project written in Java where we didn't have to rewrite in another language (C or C++, usually) to fulfill the system requirements (those projects range from embedded systems to large enterprise systems).

I used to code a huge amount in C/C++, and was a serious Java sceptic years ago, because of the hugeness of the run-time and the terrible speed (I once saw a demonstration of Swing, and could not believe how anyone could use something so slow). However, that was years ago. Things have changed. Java is no longer slow, and there is phenomenal support for Java in all scales of application. If I were having problems with Java for large applications I would absolutely not translate to (for example) C/C++ under any circumstances - you lose so much, especially portability between servers, which is critical these days. As Java is THE key enterprise development language, I would be sensible enough to realise that any problems were mine, and not the language.

Regarding embedded systems, the situation is different. Real time Java is 'cutting edge', and I would be cautious, and would certainly consider C++ for some applications. The J2ME system has lots of limitations that can restrict its applicability (although there are alternative Java versions that are more powerful, such as Waba).

I'm not out to argue; I just feel that when someone objects to Java for years-out-of-date reasons like 'Java is interpreted', I should correct this, as I believe that a modern high-performance garbage-collected OOP language like Java is a important step forward for the software industry, that has been (and still is) suffering severely from the misplaced use of lower-level languages like C++.