Popular @
Forum Controls
Spotlight Features
The Rich Engineering Heritage Behind Dependency Injection
Andrew McVeigh takes us on a tour of the rich heritage behind dependency injection, what it represents, and tells us why its here to stay.
NetBeans 6: Matisse Updates
NetBeans 6 delivers great updates to the Matisse GUI builder. Spend a few minutes with Roman Strobl and get an expert briefing on what's new and what has changed. (sponsored)
Introduction to Groovy Part 3
In this, the third and final installation of Andres' Introduction to Groovy series, you learn about how Groovy handles variable numbers of arguments, named parameters, currying, and more about Groovy operators. Including, some new operators.
Easier Custom Components with Swing Fuse
Swing Fuse (actually just Fuse), is a framework designed to make it easier to create your own custom desktop components. In this article, Daniel Spiewak shows you how to get started and provides sample source code you can download.
Benchmark Analysis: Guice vs Spring
Willam Louth shows how he uses JXInsight Probes to investigate probable performance issues with code bases that he is not familiar with. He also highlights possible pitfalls in creating a benchmark, as well as in the analysis of results.
Replies:
8 -
Pages:
1
John Carmack: Doom's Designer on Java
URL: John Carmack's Blog
At 9:37 AM on Mar 29, 2005, Sebastian Ferreyra wrote:
Fresh Jobs for Developers Post a job opportunity
John Carmack, the creator of Doom and Quake, is delving into J2ME game development with a game called DoomRPG and blogging about the experience. In the post he talks about the good and bad things he finds with developing in Java in general, and for mobile platforms in particular.
I find his comments interesting. He's an experienced and succesful programmer with a fresh look into Java and he sees things we might take for granted or have grown accostumed to ignore.
He talks about gripes typical to developers with low-level programming backgrounds, like no unsigned integers, not being able to turn off strong typing, but he' s not seriously concerned with these, his biggest concerns being the low performance of Java in mobile devices and code portability.
He finishes saying he would probably prefer writing games in BREW, the competing mobile device game development platform, which can be used with C/C++, although he does give Java a thumbs-up because no other platform makes it possible to have working code so rapidly. BREW also has one fourth the market share Java has.
Sebastian
8 replies so far (
Post your own)
Re: John Carmack: Doom's Designer on Java
I was actually rather surprised at first that he would have positive statements about Java or J2ME.The thing about the terrible WORA on J2ME devices is a real shame... this was a problem 2 years ago when I looked into the platform, and it doesn't seem to have gone away yet. I hope Sun can get this under control by kicking some licensing ass with the MIDP handset providers...
@People familiar with BREW:
I don't really believe that there are absolutely no incompatibility problems with BREW... the J2ME trouble stems mostly from bad code on the native host system, like audio drivers not supporting some audio formats, or input devices that slightly vary from handset to handset. This is mostly a issue that is caused by the integrator (of J2ME), I think. So, if you're familiar with BREW: do you have
similar experiences? Or does BREW have some magic facility that prevents this?
@J2ME experts:
I'm surprised that the speed of J2ME devices hasn't picked up with modern JIT or Dynamic Compilers from Sun and others.
Does anybody have any info if those are used? Or are most mobiles still using software interpreters?
Is the ARM Jazelle CPU support used in any mobile handset?
Re: John Carmack: Doom's Designer on Java
> A couple of years ago I saw a C++ API that have javadoc-like documentation generated using something called oxygen (I think). It made me realize how I had been taking Javadoc for granted. It's one of those things you don't know you rely upon so heavily until its taken away (or you recall the time before it). > Again, I'll say that I've worked in lots of environments where we develop Java on one platform, and deploy on another. We've seen quirks in the form of bugs in VM implementations, but no quirks due to oversight or looseness in Java's specifications. I say the portability *is* real, at least in the contexts I've seen it. That's not to say that J2ME has received the same attenion and effort. Its probably more difficult with all of the "configurations" and "profiles" for J2ME.Re: John Carmack: Doom's Designer on Java
On the subject of WORA, I too have written portable code using Java, and I have written portable source code using languages like C++. And I have seen Java code that was decidedly non-portable. One manager swore off Java forever because of such a project.Yet, I think this manager was being unfair. The problem was not with Java. It's possible to write non-portable code using Java (as was done in this case), just as it's possible to write portable code in other languages. The key is that you must have portability in mind and pursue it in your design. That said, Java makes portability oh so much easier than, say, C++.
Not knowing enough yet about J2ME, I wonder whether the portability issues with J2ME are of the same nature.
> ... C++ API that have javadoc-like documentation generated
> using something called oxygen (I think)...
The tool you're thinking of is Doxygen, a very nice doc tool for C++ and other languages. And, yes, when doing Java, it is really easy to take Javadoc and JUnit for granted. It's quite a switch then to go back to C++. True, similar tools are available for C++, but the Java tools are clearly more mature.
-TimK
team-oriented object-oriented Agile
C++ Perl Java assembly embedded systems
Portability
> On the subject of WORA, I too have written portable> code using Java, and I have written portable source
> code using languages like C++. And I have seen Java
> code that was decidedly non-portable. One manager
> swore off Java forever because of such a project.
>
> Yet, I think this manager was being unfair. The
> problem was not with Java. It's possible to write
> non-portable code using Java (as was done in this
> case), just as it's possible to write portable code
> in other languages. The key is that you must have
> portability in mind and pursue it in your design.
> That said, Java makes portability oh so much easier
> than, say, C++.
I think an important distinction between portable C/C++ and portable Java is whether the source code or the binary is portable. In C/C++, you are right, you can write portable code. But can you run the compiled C/C++ binary on any platform? With Java, so long as your code was written to truly be cross-platform, your compiled binary is too.
This distinction isn't as important in my job, but I imagine there are situations where it is more important, such as distributing a J2ME game as bytecode rather than maving people compile it on their phones.
Re: Portability
I know nothing about cell phone game development, but I'm guessing they just download the right binary for your model.Re: John Carmack: Doom's Designer on Java
Its amazing how he can be so right and so wrong in one article.1. Portability 1: There are historically issues with portability - this has little to do with VM implementations (although that has occurred) and more to do with API availability.
People often miss the fact that cellphones are mass market, low value devices. Manufacturers will do everything they can to reduce costs to improve their (narrow) profit margins. When it comes to j2me the landscape has been evolving rapidly and some manus decided to enhance the basic spec to take advantage of their devices - and in other cases to take the spec a little too literally (not good when its woolly in places) - and of course fitting a standard api onto your custom hardware can be awkward sometimes - it may "just work" (which seems to often happen) rather than following the spec explicitly.
2. Portability 2: The main thrust of j2me is of course game design - and games inherently aren't that portable. They can't be forced into using common demoninator UI controls - they want to take advantage of the screen size and paint custom sprites everywhere - and this means having different sized resources, different layouts (one screen is 176x208 another is 96x65 another is 128x116 ... it goes on and on).
You CAN make this more portable by driving it from resources - except space/performance requirements can hinder you. Sometimes its just that bit quicker and smaller to put the constants in code, rather than parse them from a file - when your upper limit is 64k or as it used to be 30K that's VERY important.
3. Portability 3: Performance, performance, performance. Again we're talking about a huge range of performance - from phones with 4Mhz processors and 30K of heap - to phones with 250MHz processors and 10MB of heap (or more!). Then there's the main reason for slowness - the IO bottleneck - many phones have near constant time screen IO - so a write of an image takes (nearly) the same amount of time regardless of whether its an image of 176x208 or 16x8 . On some phones this bottleneck can mean a latency of 200ms or more - you just have to code around it (hurting portability of course).
4. MIDP Debugging ... well I will curse the standard WTK and most handset manufacturers emulators - they are dog slow - and generally speaking bear little resemblence to the real devices. But when it comes to devices - again they're cheap - adding a specific debug interface for the Java will be relatively expensive. So if its slow its slow.
5. BREW has nowhere near 1/4 of Java market share - perhaps in the US - but worldwide it has virtually no penetration.
He's right when he says for gaming cellphones need dedicated input devices - but he's wrong to bitch about the existing keyboard interfaces - it doesn't really matter whether this is Java or BREW or "whatever" - it boils down to cheap hardware - the keyboards are designed for cellphone usage - 1 key at a time - not for gaming - its cheap. Perhaps as the electronics become more commodity (and cheaper) we'll see a change here.
You can almost feel John Cormack optmising the vending of his blog as you read it - one has to have a huge amount of respect for the man - but he does seem to have not learnt the lesson of premature optimisation.
Re: John Carmack: Doom's Designer on Java
>> 2. Portability 2: The main thrust of j2me is of
> course game design - and games inherently aren't that
[snip]
Interesting. Makes sense however, as his portability comment does not apply to Java in general as other posters have pointed out. It's very impressive to see fairly sizable Java apps (1000+ classes, many libs - Struts, etc) able to be deployed to a mainframe running WebSphere.
Further, the fact that he mentions there are 100+ platforms out there, is impressive enough, when most folks give up on Netscape/Mozilla conformance, and just build for IE for example.
>
> 3. Portability 3: Performance, performance,
> performance. Again we're talking about a huge range
> of performance - from phones with 4Mhz processors and
> 30K of heap - to phones with 250MHz processors and
>
Yes, that comment was rather vague - he's comparing a phone to a Game Boy Advanced? This is hardware that is specifically designed to run games. Games are a few down the menu on my Nokia phone.
>
> 4. MIDP Debugging ... well I will curse the standard
> WTK and most handset manufacturers emulators - they
[snip]
Further, he notes he is using NetBeans (not sure if that was the MIDP debugger he was complaining about), then complains about the slowness of text editing. That's the IDE, not necessarily Java. And NetBeans is designed around building J2EE apps, if speed is the priority there's always vi.
>
> 5. BREW has nowhere near 1/4 of Java market share -
> perhaps in the US - but worldwide it has virtually no
> penetration.
>
Another one you can use to write C++ apps in Qtopia, by TrollTech, the same folks behind the Qt toolkit, which is used by KDE. It would be interesting to see a performance comparison though, rather than Cormack's subjective comments.
A correction to the original post, he doesn't exactly say he would "prefer" BREW over J2ME, just that he *thinks* he'd like working with it, but hasn't because of it's more proprietary nature (didn't work on his phone apparently). So overall, a plus for NetBeans and J2ME.
>
Re: John Carmack: Doom's Designer on Java
> Write-once-run-anywhere. Ha. Hahahahaha.Following up on this comment, here's a link to a recent SDN Chat transcript that addresses this issue on mobile devices. The term coined up for it is Device Fragmentation.
Here's the introduction quoted:
Seb