Viability Of Java For Games

My game Crypto Hex is made in Java. For some people Java is a dirty word. I’m not convinced that the hate is justified, but there are definitely some trade offs you have to take when writing games in Java.

After writing my own game in Java, I wanted to sum up the viability of Java as a platform for making games.

Lets take a high level look at the main issues around using Java for game development as I see them.

Performance

Java programs run in the Java Virtual Machine (JVM) which manages the memory of the application for you. It does this by keeping track of references to objects and releasing memory as they go out of scope. Unfortunately there’s a performance overhead when this “Garbage Collection” takes place and the developer has very little control over it. In addition a lot of geeky memory optimizations that C++ programmers might be able to use are not possible.

Bundle Size

If you plan to deliver your game as a downloadable application then you probably want to bundle the JVM with the game. The alternative is to ask your user to install the correct version of Java before they can play your game, which is a little clunky. However the JVM is currently about 70mb after compression. For a small game this can be a significant addition to the size of the download.

Startup

The JVM does a lot of clever runtime optimizations based on how the program runs. This can actually make the performance of Java overtake C++ in certain scenarios. Unfortunately the developer has no control over it and it usually takes a little bit of time for the JVM to recognize which optimizations will help. This results in your program not getting up to full speed straight away. While it takes very little time for the optimizations to occur the performance gains are not available at the very beginning of the program and when performance critical sections occur for the first time. First impressions are everything and I would prefer my program to start at it’s fastest speed.

People certainly have other issues, but it’s usually splitting hairs about language issues. I like designing programs in Java a lot. In fact it’s probably the main reason I use it. It’s not perfect by a long way, but it’s a very good language for designing large programs in. Rather than put forward my own arguments (which I’m not really qualified to make) I’ll probably just point out that a lot of other smart people choose to use Java, Google for instance even made GWT to cross compile Java into JavaScript (more on this later).

Of the issues I mentioned the only one that can really sink the idea of using Java for games is the first one, performance. So let’s go into more detail in that issue.

Memory Management

The root the issues is the memory management. The Garbage Collector can cause the game to pause visibly while it cleans up old objects on the heap. Typically the garbage collector is triggered when the program has filled up the heap. At that point the whole program pauses for a couple hundred milliseconds, depending on the program and hardware, while the Garbage Collector does it’s thing.

There are two schools of thought on how to deal with this problem.

Never Release Objects

Some clever developer realized that so long as you keep using the same objects over and over then you can stop the Garbage Collector from being triggered. You can do this by using object pools so you can reuse your old objects instead of allocating new ones.

There are a lot of problems with this approach though. Firstly there’s a design overhead to using object pools. This is going to make your program take longer to make and be more bug prone.

Secondly, you can’t control the allocation of objects from within the libraries you use. You could try to not use any API calls to other libraries, but you’re really tying your hands now.

You’re really just delaying the inevitable with this approach.

Never Hold onto Objects

There’s another way that involved using a different Garbage Collection algorithm. Yes you do get some control over the Garbage Collector, you can specify from a couple of different algorithms it can run.

The Concurrent Mark Sweep (CMS) collector is made to reduce the pause time of the Garbage Collector when it runs. I reduces it by an order of magnitude. Enough to happen mid frame and not cause a noticeable pause.

But you don’t get this for free, there’s a trade off. The CMS actually splits the heap into two sections. One section works like the typical Garbage Collector and has a long pause when it needs to be cleaned. The other section has a very small pause.

Newly created objects go into the quick section of the heap. If the newly created objects persist for a long time then they end up moving into the slow section of the heap. So long as you never fill up the slow section of the heap you never get the long pause.

In order to take advantage of this you want to make sure your objects have small lifetimes. You can have some persistent memory that has a long lifetime. But frame to frame the objects you create are released before the next frame.

At this point alarm bells might be ringing in some C++ developers heads. They know that creating objects on the heap is expensive. In the case of C++ that’s right. But in Java creating objects is very cheap. Without getting too geeky, this boils down to the fact that in C++ when you allocate memory on the heap you have to find a space for it. In Java the heap is allocated sequentially, so it’s more like allocating on the stack. In java you pay for object creation when you clean the object up instead of when you create it.

Using this approach has some other advantages. Some of the JVM optimizations will actually bypass allocating memory on the heap altogether for very short lived objects. This can happen for objects that never escape a small method.

More Reasons To Use Java

So if you can get over the performance issues, which you can for all but the most intensive cases, there are a lot of nice things you can get from programming in Java.

The most obvious is compatibility. You can release on PC, Mac, Linux, Android and Web all from the same codebase. Although you'll probably need to make some adaptions to your graphics layer for Android and Web.

Java is a very prevalent language on servers. In fact OpenShift will let you run java programs on their servers for free. Being able to easily deploy a program with a server back end for free opens up a lot of possibilities for indie developers.

In the end the main reason you might want to program games in Java is because you feel most comfortable using it as a language. There are certainly better choices if you're looking for a new language to make your game in.

But in spite of what people say, Java is a very good language to design programs in and I want to reassure Java developers considering using Java to make a game in that it is a very viable language.