Reasons Java is a good Game Development language

[kevglass]

I felt guilty for posting negative press about my beloved Java, even if it was the truth from recent experience. So, negative impressions of applets aside, why is Java good for game development? A few thoughts from my POV:

1. Productivity - Java is by far the most productive language I’ve ever worked in (though there are obviously quite a few I haven’t tried). The language lends itself to writing good quality maintainable code but in the same breathe lets you prototype at top speed.

2. Rich and Stable SDK - the SDK to second to none in feature set and quality. It’s painful using other languages after having the Java SDK to hand. More over it’s getting bigger and better all the time (JBDC 4 amazed me for instance)

3. Mature Platform - Java has been around 10+ years now and is used everywhere. Outside of the games world it’s an incredibly popular language meaning that the platform is always being tested on the grand scale. Due the open process the whole thing revolves around this always means that bug reports and fixes are always coming in (though not always appearing quickly enough)

4. Quality Tools - whether you’re a Idea, NetBeans or Eclipse fan - we as Java developers have the best general development tooling there is. The Java development tool set has been around almost as long as the platform and since (in the majority of cases) the tools are written in Java, they also benefit form the above.

5. Library integration - we have a fantastic integration with the core open gaming technologies via LWJGL (and some other libraries as I understand :)). OpenAL, OpenGL and input variants are all available to us with minimal effort. (what we could do with here is the DirectX binding sorted out).

6. Cross Platform - For desktop and browser based games we have minimal porting work to get from Windows, to OSX, to Linux. Even more than that, if you learn to use Java you can go to J2ME and Android getting you onto the mobile platform. Now with BlueRay taking the lead we’ll be able to use Java to develop to the massive number of players that’ll be around soon. (what we could do with here is integration with some console somewhere).

7. Performance - Java is fast, really fast. Ok, you can better it with some time consuming work in the C world but where managed languages are concerned it’s damn quick. Looking at games development and comparing to Flash et al, it’s really obvious that Java is fast.

8. Community - Even though Java is seen as the underdog in the games development world the loyal community are still producing great projects like Xith, JME, ODE, JBox2D, PulpCore, JPCT, JOODE, JBullet, GTGE and LWJGL to name a but a few. These enablers are making it quicker and easier to prove how good a platform Java really is. The high quality of these technologies is partly due to their diligent authors, but partly due to how powerful and constructive Java is as a language.

So while I’m finding other technologies endearing for custom tasks at the moment I can’t help but thing the future of games development is going to include Java.

Kev

[ewjordan]

[quote]4) Quality Tools - whether you’re a Idea, NetBeans or Eclipse fan - we as Java developers have the best general development tooling there is. The Java development tool set has been around almost as long as the platform and since (in the majority of cases) the tools are written in Java, they also benefit form the above.
[/quote]
Let’s not forget Javadoc - this, to me, is the killer feature of Java that has not been adequately mimicked in any other language that I know of. The fact that all the IDEs integrate Javadocs so seamlessly increases my Java productivity by a massive factor because even when I don’t know what call I need to make I can browse for it in a quick popup right from Eclipse, without popping up a separate window or anything. As much as I love languages like Python and Ruby for their power and ability to do complex things with very little code, using libraries that I haven’t written is, quite frankly, a pain in the ass because the level of support for documentation browsing is not on par with Java.

[quote]7) Performance - Java is fast, really fast. Ok, you can better it with some time consuming work in the C world but where managed languages are concerned it’s damn quick. Looking at games development and comparing to Flash et al, it’s really obvious that Java is fast.
[/quote]
And it’s only going to keep getting better. The more disparity we have between processor speed and memory access, the more important it will be to be using managed languages that can reshuffle memory as needed based on usage patterns instead of prior planning. There are already situations that show up in real life where Java can outpace the equivalent C code with no effort on the part of the programmer, and as the JVM gets better (and if they hopefully allow more optimizations into it!) these cases will become more and more prevalent.

To be fair, this is more an argument in favor of JVM languages than in favor of Java; but I consider other JVM languages to be similar enough, since you still get a decent amount of interop between them (what fun would Scala be if you couldn’t use all your favorite Java libraries along with it, right?).

[quote]1) Productivity - Java is by far the most productive language I’ve ever worked in (though there are obviously quite a few I haven’t tried). The language lends itself to writing good quality maintainable code but in the same breathe lets you prototype at top speed.
[/quote]
Not sure that I entirely agree here about the “by far” part - Java lends itself to a lot of bloat, boilerplate, and pattern abuse, and for larger projects this can start to hinder maintainability. I tend to find that even for prototyping you have to spend a lot more time in the “design” phase to end up with decent Java code than you do in more dynamic languages, and for prototyping that’s a bad thing. But to be fair, some of these problems will be addressed by the addition of closures (something I’m looking forward to a lot, and also something that I never thought would get in), so at least progress is being made.

[quote]So while I’m finding other technologies endearing for custom tasks at the moment I can’t help but thing the future of games development is going to include Java.
[/quote]
Absolutely, I think that’s dead on. My personal hopes are for Android to really take off, which would put us all in a great position (esp. since they’re not using a J2ME implementation, which means all the J2ME devs are no better situated than the rest of us to target the platform).

[Riven]

The sole reason not the ditch Java for me is Eclipse & CTRL+SPACE & CTRL+F & SHIFT+ALT+R.

Writing in any other language is a Royal PITA, as productivity is gone.

_{Further, stacktraces! Very good stacktraces! Stacks that do not even exist anymore due to the JIT, are very nicely reconstructed in Java's stacktraces. Did I mention clickable stacktraces? And getting stacktraces from any thread at any time? I love stacktraces... and reflection, which throws a bit too much stacktraces.}

[Demonpants]

Stacktraces are awesome!

Java is awesome!

As for Eclipse hotkeys… I like Control-Shift-M myself, so I don’t have to type import so many times. Especially if you’ve got a big project with lots of packages.

[Riven]

CTRL_SHIFT_M is much slower than just typing your class and typing CTRL_SPACE.

CTRL_SPACE not only does autocompletion, but also manages imports.

[Demonpants]

@Riven

CTRL_SHIFT_M is much slower than just typing your class and typing CTRL_SPACE.

CTRL_SPACE not only does autocompletion, but also manages imports.

Well you learn something new every day. ;D

[gouessej]

@kevglass

7. Performance - Java is fast, really fast. Ok, you can better it with some time consuming work in the C world but where managed languages are concerned it’s damn quick. Looking at games development and comparing to Flash et al, it’s really obvious that Java is fast.

Java can be even sometimes faster than C/C++ ;D Watch Jake2.

[Riven]

Jake2 has a layer between the OpenGL calls from the engine, and the OpenGL calls reaching the hardware.

It converts immediate mode to vertex arrays.

So Jake2 is only faster, because it changes the rules, not because the JIT outperformces C/C++ code.

[bienator]

@Riven

Jake2 has a layer between the OpenGL calls from the engine, and the OpenGL calls reaching the hardware.

It converts immediate mode to vertex arrays.

So Jake2 is only faster, because it changes the rules, not because the JIT outperformces C/C++ code.

exactly.

additional to that the comarison would only be fair if they recompiled quake 2 with latest c compilers - I am not sure if they’ ve done that.
An up 2 date benchmark on newer hardware and java 6 would be interesting nonetheless.

[princec]

I’d have to get all realistic on your asses at this point and strongly urge you to pull your performance heads out of the cloud Java is typically about 50% as fast as C++, and with the server VM, you can get to a typical 80% or so, but with totally unacceptable startup time. Hope that 2 tier compiler comes soon!

Cas

[kevglass]

This is the most recent (and appropriate) benchmark I can find:

http://www.irrlicht3d.org/pivot/entry.php?id=446

Java isn’t as fast (or faster) than C/C++, but it’s been getting less and less important - future = Java

Kev

[princec]

Yep, that pretty much is spot on for the state of benchmarking.

Cas

[DragonsRage]

“I was able to make the C++ version take 16 seconds for the nested loops-test while Java only needed 1 second by adding some virtual method calls which I knew Java could optimize. I also was able to make the C++ version run in only 78 ms while the equivalent Java version needed even 10 seconds by only using static loops - the C++ optimizer then would not even loop anything and just add the values together.”

I was surprised to see the findings on the loop calls, it seems that the programmer’s knowledge is also a determining factor in speed.

[admin1]

@bienator

exactly.

additional to that the comarison would only be fair if they recompiled quake 2 with latest c compilers - I am not sure if they’ ve done that.
An up 2 date benchmark on newer hardware and java 6 would be interesting nonetheless.

At the end of the day, playability is what really matters. I have become, over the years, less of a purist about Java and we need to look at this realistically. Use Java for it’s inherent strengths and, where is makes sense, use supporting components. I really do believe that it is much better and efficient to look at fewer components that need to be ported than an entire code base.

Who cares if they changed the rules? If it made the game more performant and still allowed for the advantages of Java, then great in my book.

[Riven]

@ChrisM

Who cares if they changed the rules? If it made the game more performant and still allowed for the advantages of Java, then great in my book.

Yup, just clearifying that this speedup was not due to the JIT or the JVM in general.

Anyway, if you’re not creating AAA titles, ‘only’ having 50% of performance is normally not a problem anyway. Often optimizing your code and algorithms yields much more performance gain than doubling raw execution speed.

[princec]

You will be pleased to know that AAA titles can be written in Java too - it doesn’t matter if the CPU usage is twice that of the C++ counterpart as the breadth of different machines that it has to run on - from 1 to 4GHz - and the massively different capabilities of the graphics chipsets - means it’s largely irrelevant for most purposes. The C++ equiv. will be optimised to produce 60fps on a 1GHz machine, for example; if the Java version only achieves 80% of the speed, then it’ll run at 60fps on a 1.2GHz machine instead.

Cas

[Riven]

Err… 1.00GHz/80% = 1.25GHz :persecutioncomplex:

Anyway, in AAA titles (like Crysis) it really matters whether you get 100% or 50% of raw execution speed, as it is targeted at top end PCs only. Same for AAA titles on the consoles (where you have a fixed specification of hardware).

Nobody in their right mind writes for top end PCs though, so yes, every ‘regular’ AAA title can very well be written in Java.

[bienator]

@ChrisM

At the end of the day, playability is what really matters. I have become, over the years, less of a purist about Java and we need to look at this realistically. Use Java for it’s inherent strengths and, where is makes sense, use supporting components. I really do believe that it is much better and efficient to look at fewer components that need to be ported than an entire code base.

yes. Can you tell me why everyone tries to write flash games in java and consequently tries to avoid every of java’s inherent strengths?

To get hardware acceleration you need native libraries because things like graphics drivers are not written in java, no one said native code is a bad thing…

@ChrisM

Who cares if they changed the rules? If it made the game more performant and still allowed for the advantages of Java, then great in my book.

I care, thats why I said it would be cool to repeat the benchmark with newer hardware and software. I am software developer and therefore interested in technology and this is a technical topic - thats why I care.

Saying that (in _this _particular _case!) java is faster because of a JIT and higher GC driven memory throughput, is just wrong. I can’t say it better than Riven… they changed the rules. They render Quake in a more efficient way as it was possible as quake was released (because of hardware and driver capabilites).

But don’t get me wrong. Imagine this scenario:
Two teams get the task to rewrite Quake2 without looking at its original code, one team in language A the other in language B. If they finish with almost the same code, at least one of them made something wrong. Why? Because you almost certainly don’t solve in two different languages the same problem in the same way… thats the main reason why we have more than one language because they fit best to certain kind of problems.

Comparing software is extremely difficult. I would even say comparing languages performance wise makes only sense if the languages are almost identical.

[DragonsRage]

@bienator

Comparing software is extremely difficult. I would even say comparing languages performance wise makes only sense if the languages are almost identical.

I completely agree with this, but comparing specific tasks in programming languages in terms of performance can be useful because you want to pick the right one for the job. Comparing them in general and saying one is always or usually better, probably isn’t going to be useful nor meaningful.

[princec]

WRT performance the argument finished with Java and C++ some years ago now - the performance difference even in the most awkward situations doesn’t warrant a decision to use one or the other for clientside or serverside. It’s moved on to maintainability, speed of development, and ease of deployment, where the story is dramatically different for both platforms.

Cas