ENJOY A few paragraphs about J2ME, BREW and the like. I figured that if nothing else, he'd complain about connectivity issues. DISCUSS LIKE YOU'VE NEVER DISCUSSED BEFORE!

Yes, I saw that in the lounge right after I visited this board. *smack*

Anyway, I get the feeling that most Java developers are going to take this as a bright omen (especially those who take their cues from him). So what exactly do you guys think he meant by "3D space" on the phone?

It'll be interesting how the Doom rpg actually works and on what handsets it'll be eventually working on - testing on 4 probably means just the high-end ones at present...

First and foremost, he's not saying anything new here. The issues he talks about should be readily apparent to most people from practically the beginning. Now, let's actually talk about those issues.

The security model and the java class stacks are the main problems, I believe. If there were a compile time switch "Turn Off Array Bounds Checking" or something, it would help a lot. I think when there is so little data that I can actually count it on my hands and feet, then it is my own responsibility to make sure I don't go out of bounds. We've done it for years in C/C++ in really large applications, we can do it now in really, really small ones, it's not that hard.

The class stack is also an issue. There is just too much going on. I've only just started to learn about CLDC and MIDP, and already I can see that "It's a really cut down version of the JVM" means "but it's not cut down enough." GBA code in C is simple and lightweight, "simple" java midlet code is not.

I do like how the components (displays, input devices, sound players, etc) are all really compartmentallized, and you only have to import them if you want to. Too bad it's still really slow.

From coding on the GBA, it seems "right". The device boundaries are small enough that you can manage memory in your head. The interface to everything is extremely simple, you are just copying values from here to there. I think that programming games for cell phones should follow the model of the GBA, and this could very well be possible if the JVM were cut down to just a unifying layer over the hardware. Don't give us any drawing primitives, I'll write that myself, just give me access to the frame buffer, give me access to the sound buffer, give me access to some basic input, and I'll figure it out from there.

Grand Unified Theories of Cross Platform Wireless Communication are pipe dreams. For gaming, I doubt you would ever write a cell phone game that would communicate with another, different game, so writing your own protocol on top of the simplest possible communication interface is wholely feasible.

Doug Twilleager blames the bad implementations of Java on most mobiles, given that (he claims, I haven't yet looked to verify this) most mobile manufacturers are happy to still include interpreted Java, as opposed to JIT compilers or Java processors, as well as the massive differences between mobile models as well as families, not to mention vendors...

Basically, it seems that Java on a moblie just isn't standardised enough yet in spite of what is already there.