Java for games: pros and cons

2010-08-17

Programmers love to trash programming languages. The more successful a language, the more likely you are to find someone who will, happily and in excruciating detail, explain its many failings to you. One of the favorite victims nowadays appears to be Java. And while Java does have its bad points, most of the criticism appears to focus around a handful of old myths that should have been put to rest long ago.

Myth #1: Java is slow.

Um, no. For years now, the Java Virtual Machine has been using a technique known as JIT (Just In Time compilation). It is the same thing that makes Javascript in modern browsers rival the speed of native code. And if it works for Javascript... Besides, in a game, most of the work will be done by various library bindings, which are natively compiled code in the first place.

Myth #2: Java has horrible documentation and an inconsistent API

Strangely enough, I hear this mostly from fans of .NET, a platform I found to have exactly these issues during my brief time with it. Must be a matter of taste. And even if it was true, there are always books, tutorials and code samples to learn from. Just like, you know, with any other programming language.

Myth #3: But, but, nobody uses Java!

No kidding! Someone should tell the makers of Runescape, an old, established MMORPG with a player base in the millions. And they are not the only ones. There are all kinds of Java games out there.

Is there a point to this?

Why, yes. See, game development is hard as it is. You'll want to pick the tools that work best for you and your current project. You really don't want to limit your options because of preconceived notions (rhyme not intended). So let's see what Java has going for and against it, respectively, based on some real-world experiences.

(Disclaimer: I've only been using Java for the past 4 years or so, and not as intensively as other platforms.)

The good: For me, the single most important appeal of Java is the distribution method. You can pack all the code and assets into a single compressed file and offer it for download, or embed it into a Web page, and as a bonus it can function as a library for future games. And if it's well written it will run correctly anywhere there's a Java runtime available, at least in my experience.

The bad: Of course, the problem lies in the last sentence above. In order to deliver all those advantages, Java comes with a big heavy runtime that has to be downloaded and installed before you can run any game based on it. And while that runtime provides a mindboggling amount of built-in functionality, it also eats up memory like crazy, most of it wasted (hint: you're not going to use a significant amount of the built-in classes in any single game).

The ugly: And then there's the language proper. While it has some definite advantages like garbage collection and introspection, which e.g. C++ lacks, its limitations are stifling. The code structure it enforces often doesn't make sense 1, the type system is sometimes too lax and sometimes too strict, and the syntax isn't expressive enough, requiring much more code than other languages to accomplish certain tasks. But for some people these are good things, so try it yourself.

That said, I've had a very good experience developing mobile games (and other applications) with Java ME. The limited scope of these projects might have something to do with it, as well as the greatly simplified API. (Come to think of it, Java was originally designed for embedded platforms; no wonder it fits them so well.) As for portability, nearly every cellphone out there supports Java ME, including various extensions. The biggest incompatibility issues stem from differences in screen resolution and hardware resources. There is even an (unofficial) implementation for the PSP, and probably other devices.

In conclusion

Would I use Java for any game? Of course not. But it's definitely an option to consider for many projects, and will remain so for the foreseeable future (at least until Oracle starts suing everyone).

OK, that was cheap. But come on...

Tags: ,

Footnotes:

1. Think very small classes that have to be placed in their own source file just because, or functions that logically do not belong to any class but have to be members of one anyway.