John Carmack decides to code a Java game for his new cell phone just for fun and writes about the problems he had with J2ME while doing so.
John Carmack’s cell phone adventures
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
J2ME is slow. Netbeans isn’t no Visual Studio (He must have been shocked to find that Swing still has horrid fonts), WORA is a myth in J2ME land, and latency is still an issue because of too much crap between the app and the hardware.
The weird thing is that the mobile Java APIs aren’t even standardised. Every mobile device has its own way to do graphics, sound etc.
Together with the slowness of Java this makes in a non-solution (for mobile devices).
Why can’t they just define a standard C API? You could actually write nice, efficient games then, and call that API from C, C++, assembler, Java, Python, Lisp, Smalltalk….
I guess that’s just not stupid and hypey enough.
> Together with the slowness of Java this makes in a non-solution (for mobile devices).
What slowness are talking about? Did you even try running Java on a phone or you’re just repeating whatever other drones just whined about? I run Java apps on my Nokia phone all the time and they run quite acceptably. Like it or not if you develop for mobile phones, Java is by far and I repeat by far the best platform there is out there.
Why can’t they just define a standard C API?
It’s called BREW, but about 75% of the wireless world is deathly afraid of the company behind it (Qualcomm).
And why are they afraid?
Java makes complete sense on the mobile.
The thing that the customer likes about Java is it is sandboxed.
There are sandboxed C versions like Morphun on the market too.
And who is this customer I talk about? The network operators. They are the ones who care.
Many chips are starting to get Java-accelerators built into their chipsets.
Some programmers do manage to make good games work well with such limited hardware.
And why are they afraid?
Qualcomm’s CDMA standards are the only things which keeps GSM from having 100% worldwide marketshare.
nice read. jc still gets it.
what about a futuristic “doom”-line of cell phones? designed for the motherload of future mobile gaming?
oh wait, forgot about that possible gsm-psp-upgrade to come.
but what about some work with nokia or some other vendor who wants to push his platform? faster “games” means faster hardware atm, which goes with less battery time. what john describes would not be so hard to accomplish.
(no brew! qualcomm is bad. lucky to not live in a cdma country…)
how cool would an id-engine for cell phones be?
(at eight in the morning one is still allowed to dream, not?)
that would surely get a lot of people to buy a new phone.
i smell money. got to mail mr carmack now. oh, just fresh java brew. 8)
:Why can’t they just define a standard C API? You could :actually write nice, efficient games then, and call that API :from C, C++, assembler, Java, Python, Lisp, Smalltalk….
Because they can’t even agree on what standard C is… Or some can but big companies doesnt follow it. Remember Microsofts version of Java?
There is a ‘standard’ if by standard you mean that one company controls it. Qualcomm controls the BREW ‘standard’ which is a C based API. Some carriers love it because it helps them to maintain control of the phones much easier. Starting to program for BREW is… well not easy since Qualcomm makes you jump through so many hoops to get the code to run.
Java is the closest thing to a standard on phones. Sad but true.
Some of the things that he says about java are just plain mean though, and based on things that are in many cases not true anymore. However, the state of JVMs on mobile phones is such that in many cases he is right. Since the VMs that run on the mobile phones are not nearly as advanced as those that run on the desktop/server. Mostly too memory constrained to do some of the cool compiliation optimizations that us server java programmers are used to.
http://www.javolution.org
I do J2ME development professionally and the handsets we have here in Japan are much better so I can say that the lack of speed is really based on the handset.
Additionally, the European handsets (Nokia and Motorola) are far more prone to bugs and idiosyncracies than those here. It’s too bad North America isn’t dominated by the likes of Sharp and Toshiba.
He should also drop netbeans and use Eclipse instead if he wants a better/faster development experience.
In closing, J2ME is far from perfect and some of what he says is true but I would recommend he form an experienced opinion on the subject after he’s put in a year or so of mobile development. Putting in a day a week for a short period of time does not provide much insight into the platform regardless of one’s internet/career profile.
If you want to code in C++, get a Symbian series 60 phone.
I don’t see many comments on speed (or lack thereof) as valid. Carmack says “about the CPU power of an original 4.77 mhz IBM PC”.
Something that is 4.77 mhz is fast for simple Java games like platformers, remember that we had many platformers on the old XT and AT series that performed great, plus the screen is only 128×128 or even smaller. But when you’re developing what seems to me to be a first-person shooter on your phone, it’s probably not going to be great.
Everyone who reckons Java is fast, run a first-person shooter on your phone, and tell me whether that is fast. Because that’s really the only valid comparison you can make.
Or a UI based device, P800 / P9x, or one of the UIQ based Motarola 3G devices…
Nice to know that even the best programmers has problems.
I looked through the HTML source in hope of seeing a link to an RSS feed and noticed this:
meta name=Generator content=”Microsoft Word 9″
🙂
I’ve developed cellphone games on top of J2ME and I must say that it’s all a big, ugly hack. What Carmack says is true, there’s no real portability and each model has its own glitches and quirks. Java is completely, totally and absolutely inapropriate for today’s cellphones. I can’t imagine running a bulky VM on a PC in the old days. And cellphones remind me so much of them when I see their capabilities. Really, you get to think about optimization on the lowest possible level, care about every bit. Therein the problem lies, because Java does a good job preventing you from going too deep. No matter how hard you try, there’s that J barrier you can’t overcome. C/assembly would be so much better. It isn’t hard to write a good secure kernel or even a library framework for a cellphone. So there’s no real excuse for Java. The present state is very unfortunate.
Anyways, I’m still waiting for an open architecture cellphone running free software. Don’t you feel constrained when using cellphones? You don’t really know what’s going on underneath, you’re limited to the provided interface. You’re just at the phone’s mercy. Imagine the possibilities of opening it up!
But that’s another topic…
What slowness are talking about? Did you even try running Java on a phone or you’re just repeating whatever other drones just whined about? I run Java apps on my Nokia phone all the time and they run quite acceptably. Like it or not if you develop for mobile phones, Java is by far and I repeat by far the best platform there is out there.
You can repeat it all you like, but the truth is there.
Java apps are slow, put a large amount of overhead on the device and are total crap. A C or C++ app would blow it away, so one can only hope Qtopia gains some traction. If it’s the best platform there is then people are in a bit of trouble then, aren’t they?
Are you the usual Java drone who tries to defend it to the hills when the truth is staring you in the face?
This article strikes me as a little funny, since Carmack is now just starting to develop a mobile phone game, and I’ve been playing one of his games on my phone for over a year now. There is (was) a port of the Doom engine for Nokia Series 60 phones. It works pretty well, and is as fast as I remember Doom being on my desktop PC when Doom was new. It’s obviously not written in J2ME though.
Doom has been ported to Symbian phones.
http://www.yipton.demon.co.uk/
Now that Symbian devices are getting OpenGL, I doubt Quake will be far behind.
John Carmack wrote:
> Even compiled to completely native code, Java semantic
> requirements like range checking on every array access
> hobble it.
That’s complete BS. Nowhere does the JLS say anything like that.
Doom? Quake? He should dig out the code for Commander Keen, that’s the type of game for a cell phone!
Like it or not if you develop for mobile phones, Java is by far and I repeat by far the best platform there is out there.
You must have not developed for Palm OS or Windows CE smartphones. Both are C and both are better than java.
I’m surprised Carmack did not consider a microsoft smartphone. They use win32 and have fast cpus.
“…Carmack is way over-estimating performance of most phones. Only the highest-end Java phones support 200k jar sizes. The majority of consumer phones are limited to 64k – even many brand new phones have this limitation. On the other hand, he’s not being 100% fair with his GBA comparison. Gameboy, GBC, and Gameboy Advance all have tile-based rendering that is easily capable of 60fps, while Java-based (and BREW-based) cell phones have only linear frame buffers that you don’t get direct access to (usually). To aggravate things, many Samsung BREW phones have 250ms response rates.
Carmack will also be disappointed when he begins experimenting with BREW. BREW doesn’t support threading, globals, or even static variables. I’m not even going to get started on the bizarre latencies of the API.
One of my jobs as a cellphone developer is to port Java games to BREW. Carmack’s comments about how fast Java phones play like 4.77MHz IBMs is true, but the same is true for BREW phones as well. I’ve only managed to squeeze another 10% out of the performance on similar BREW phones. There are a lot of things limiting cellphone performance, but Java isn’t one of the main culprits. Bad platform design and slow hardware are what kills it.”
Comment from Slashdot on the same topic
As far as Java games on cell phones go, I’ve played some extremely well done games, like “Prince of Persia Warrior Within”. It is anything but slow, it is smooth an visually rich. Some new phones even have standardised hardware accelerated 3D API, which makes Doom or similar FPS doable and playable on cellphones. Basically, some of you guys are full of it, nothing on cell phones is perfect, but there is quite a nice and big industry with J2ME, with all of the major mobile players lined up, and polishing rough edges really fast (MIDP 3.0 is on its way).
Carmack made the PC sing in Doom, etc because I had low level access. But this is a different environment. So his complaint that there’s no memset() is silly.
Does anyone know which of the Nokia phones has a decent Java VM coupled with a reasonably fast processor?
I also would like to try out J2ME development and Nokia cellphones are one of the most popular makes where I live.
My second and third choice would Motorola and then Siemens.
I have noticed that many C/C++ procedural developers that I know tend to feel this way about Java and any other OO language/platform. I believe some C/C++ developers say this because like to get down into the bits and bytes of things. While I respect John’s opinion on Java/J2ME (it is not for everyone) I think it is a bit off. He even says in his article he dabbled a bit in Java. To me dabbling is not enough to fully understand a platform or write applications for it (aside from Hello World). If you dabble in hammering nails to wood does that make you a carpenter?
I think most of us are intelligent adults that review this site, so take a step back and consider the source that is saying it. Someone who is heavily C/Assembly biased person will have a tough time seeing that there are in fact other viable options other then the tools/platform they are comfortable with. I remember when I first started learning Java back in the day… I had similar complaints that John has but then I learned that Java is just another tool, different from C++ and therefore needed to be worked with a Java mindset not a C++ one.
Some people have trouble understanding, learning and/or intimidated with new technologies and, as a self defense mechanism, try to justify why it’s inferior to what they know. My answer to that is you have to go with what you comfortable with.
I tend to be technology/platform agnostic and have implemented cell phone games with both technologies and, in my opinion, it was faster and easier to get games running on multiple mobile platforms using the J2ME standard over BREW, both having unnoticeable differences in playable performance.
From a business standpoint, the J2ME platform is less risky and can reach a broader audience faster then BREW and that’s probably why BREW is lagging behind J2ME.
On a side note, John talks about VMs being bloated… well I’m not sure how many of you played Doom 3 but even on a high end systems its pretty bloated and that’s all in pure C/C++… unless he added some assembly for optimization in there too.
Whoever wrote that comment obviously completely misread the article. johnc’s point was that phones are powerful enough to compare with the GBA _in hardware terms_ – i.e., if you could write for them in an efficient way. He DIDN’T say that *while running Java* they are capable of competing with a GBA, his point was kind of the opposite. As has been made clear in this thread, when using an efficient framework, they certainly are – Series 60 phones can play Doom, just about, and the GBA can play Doom, just about.
@Blade2xs
A the same time, he will be implementing a 3D rendering engine with it, of which he has considerable experience of over a decade on a variety of platforms. Considering Java is a bastardised version of C++, I’m sure John Carmack “dabbling” is somewhat more competent than you or I “dabbling” with Java.
First of all: BREW is not an open, standardized API, but as some people mentioned, a company standard, that nobody even implements (maybe it costs royalties to do so?).
There needs to be an open standard, just like you can look at the Java docs at Sun’s website.
Regarding sandboxing: it’s a stupid assumption that this has to be done by using a language with lots of runtime checks. OS architects rejected this probably in the ’60s already, and went on to make the hardware people implement MMUs. As John Carmack says in the article, that’s the right solution. I haven’t yet seen a whole OS running on Java, probably for performance reasons, but all modern OSes routinely run with an MMU underneath and *no language to force on you*. Use native, 100% efficient assembly if you like.
Maybe you think Java is fast; sure. All languages are fast in a way. But if you want to make the CPU do A LOT, then Java breaks down. And a mobile Java app loads slowly too (just like their desktop equivalents…).
Definitively the Nokia 6230, great J2ME phone, ieven if the 128×128 screen is a bit small :/
[Diaz Occult]
I have worked many yeas with Java and C++ on enterprise level projects and am very comfortable in either environment. I recognize Carmack’s frustrations because I ran into the same issues of control (or lack thee of). I was able to overcome these issues by pulling myself out of the C++ paradigm and open myself up to other methodologies. Carmack admits he has not spent much time on Java other then some side projects. He shares the same frustrations that many respectable developers I know had when making the transition to Java (including myself). You can see in his reaction that he is frustrated and not very comfortable with Java. You can also see he tries to solve a Java problem with a C approach. All I’m saying is that if you want to solve the problem using C then take the C approach, if you want to solve it using Java then take the Java approach. Don’t bash a technology just because you can’t make the cube fit in a round hole. You have to go with what you’re comfortable with. Java is a different paradigm then C and for some people it is difficult to make that shift.
The other thing is that the current hardware may not be mature enough yet to support a robust 3D platform. I think it is good that he is testing the limits on this but maybe he should go back to a Commander Keen port until the handsets mature a bit more. Or better yet, why not come up with original game ideas that compliment the platform instead of Doom x, Wolfenstein y, and Quake z. That may save him some frustration and keep him sane enough for his next game.
Allowing C and C++ programs to be downloaded and ran on your mobile would be the worst idea ever. How long do you think it would take for virus writers to take advantage of buffer overflows? C and C++ are completely insecure programming languages and are the reason why we need so many software code reviews and daily patches just to log onto the internet. I’m not saying Java is perfect, but it has no undefined behaviour and no buffer overflows which only leaves room for security flaws in protocols (which you can’t easily/automatically eliminate in any current language).
And please spare me the “good programmers don’t make mistakes” arguments. An application programming language should not allow you to create security problems just by copying data into an array, and this is the cause of 90% of security problems at the moment even from professional programmers and development companies.
I still don’t understand all the fuss. Carmack is just saying what anyone who has done cell phone game development already knows. You can find all of this info in articles in Game Developer magazine or in various other places around the web that deal with cell phone development.
Allowing C and C++ programs to be downloaded and ran on your mobile would be the worst idea ever. How long do you think it would take for virus writers to take advantage of buffer overflows?
Uhm. Buffer overflows? I didn’t realize phones had a security model. As I understand it, the APIs give you access to do pretty much anything you want on the phone, so you don’t need to do a buffer overflow. You just write the code.
> Regarding sandboxing: it’s a stupid assumption that this has
> to be done by using a language with lots of runtime checks.
> OS architects rejected this probably in the ’60s already,
> and went on to make the hardware people implement MMUs. As
> John Carmack says in the article, that’s the right solution.
> I haven’t yet seen a whole OS running on Java, probably for
> performance reasons, but all modern OSes routinely run with
> an MMU underneath and *no language to force on you*. Use
> native, 100% efficient assembly if you like.
You have just discovered that hardware accelerated address mapping is faster than non-accelerated bounds checking. Congratulations, but has it come to your mind that the reason for that is the hardware acceleration, not the mechanism?
I blame Java for bringing bad reputation to a good concept.
> > Allowing C and C++ programs to be downloaded and ran on
> > your mobile would be the worst idea ever. How long do you
> > think it would take for virus writers to take advantage
> > of buffer overflows?
>
> Uhm. Buffer overflows? I didn’t realize phones had a security
> model. As I understand it, the APIs give you access to do
> pretty much anything you want on the phone, so you don’t
> need to do a buffer overflow. You just write the code.
Some Nokia ppl told me that at least here in Finland the mobile phone manufacturer has to have some contract with the GSM network companies, and that such a contract makes it the phone manufacturer’s responsibility that the phone software behaves correctly. That would make it unlikely that the phone manufacturer would allow 3rd parties programmatic access to the phone’s main memory.
It wouldn’t surprise me if this was complete BS, though. (It wouldn’t be the first time Nokia ppl lied.) However, even if it’s true one could still have an MMU, or another processor (with separate memory) to execute 3rd party programs. Even so, if the 3rd party app receives data from outside (e.g. if it’s a multiplayer game) you could still use a buffer overflow vulnerability in it to execute your code on the other person’s phone, and that code would probably be able to do whatever said 3rd party app can do.
The mobile edition, for efficiency’s sake, has no bytecode verifier, so on one mobile phone Java code could completely circumvent the security model and execute arbitrary code.
Unfortunately I don’t have the source. Anyway, the bug has been fixed AFAIK, but there’s no reason you should trust a downloaded Java or Flash anymore than a C application.
Why not sandbox like Unix does (maybe more; don’t even allow a game to write files, except into the savegame directore)? I don’t see why people always jump from one thing (the need for sandboxing) to wrong conclusions (a language with extensive runtime-checking)?!?! One has *nothing* to do with the other.
Please lord, have a “Thou MIDlet Developers are alowed to whack thee developers of bad, barely complent JVMs with sticks” clause.
> don’t need to do a buffer overflow. You just write the code.
If the JSRs exists, same is true in J2ME land. Afterall, its the users data & airtime thats importent, and “hacker” could easily write a J2ME app (using 120 & 129) to delete contacts & appointments, and SMS to all your contacts “Try this great J2ME game!!”.
“It doesn’t surprise me that a programmer like Carmack has this opinion. Java sucks everywhere, be it the client, server, or phone.”
Aren’t you the main jedit developer?
Instead of impugning the content of what John said, you chose to promulgate that the source of his contention lies within ignorance. You’ve offered vague generalizations that are essentially straw men, claimed to be unbiased while taking positions that would make any reasonable individual consider that you’re a Java zealot, and even attempted to brush aside the issue by suggesting that the problem lies within the current state of the performance capacity of phones.
Perhaps you can provide some technical suggestions or criticisms rather than ad hominem.
I have done few J2ME games (mostly for Nokia 40 series). J2ME 1.0 is standard platform but standard package have too much limitations(minimum screen size BW 96×96. what a hell..). All major phone manufacturers made their own “extensions”. Like nokia “FullCanvas”, it was nice, but goodbye support for Motorola, Ericcson, Siemens,… And they even made same mistakes with J2ME 2.0. All fancy (but this time specified) 3D api’s etc. were made optional, not part of the standard package. We can only hope all phone manufactures support optional pacgages.
Portability with J2ME sucks but at least writing code is easy.
I have also tried program for Nokia Series 60, supported also by some other manufactures(Samsung, Siemens). Eiter you have commerical software IDE (Visual studio, Borland, Metroweks) or it takes about two weeks to set up environment just to compile your application.
Then the worst part. Who the hell desinged this platform(Symbian?)? Hello world – 200 lines of code? Drawing graphics – 1000 lines?
I just can’t understand how they can fuck up platform so badly.
Now I just wait until manufactures came out with something as simple as SDL.. Hmmm my Nokia 6630 seems to have ARM 200 MHz processor, meybe there will be Linux port some day
So it is really that bad with Symbian…
I only remember trying to develop for my Palm 500. Proprietary file and executable formats, no dev-kit for Linux, und syncing didn’t work either under Linux. Two weeks later I just sold it, was stupid b/w anyway.
Why can’t anyone just release a platform together with some headers, where you can compile programs with standard GCC (for ARM of course), and just copy the file onto the phone? What’s so hard about that?
I don’t see any reason in compilation technology that would justify having to get a Windows PC (I’m a mac user now) to install a weird proprietary dev environment. Just tell me the binary file format (ELF, COFF …) and give me headers to compile my stuff with *any* compiler I like. Thanks. I can’t wait for lots of Linux phone to hit the market, just because there nobody can f**k it up!
BTW the write-once-run anywhere Java doesn’t even provide a full dev environment for the Mac. For some reason they have an emulator that they can’t seem to port to the Mac — and you would think that 32 GPRs would be heaven for any emulation developer! Or you would think that an emulator that just shows you what your program would do with the J2ME API could be written in 100% Java (since it only has to emulate the library, not??).