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 ((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.)), 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...

Comments

One place where Java performance is still problematic is if you have to do any sort of low-level pixel-pushing or bit-fiddling, but fortunately those use cases are pretty rare nowadays, especially now with widespread GPU support and programmable pixel shaders.

Personally I do think that the standard Sun Java APIs are pretty craptastic, and it would be nice if there were a way to do direct pass-by-reference on POD without cumbersome hacks like sending one-element arrays down, but as a language goes, yeah, Java’s not bad.

fluffy

If by “standard Sun Java APIs” you mean Swing, then I have to agree. Fortunately you don’t need it to make a game. Or do you mean JOGL? I’m yet to do any OpenGL in Java.

Felix

I have been working on my own pet project (in java using jogl libraries) for some time, and I have to admit it – the main reason I use it (besides the fact that is the language I know best) is the easiness of handling stuff which otherwise would take “centuries” for one man to put together – in other words: it saves a LOT of time.

I have been doing a small prototype in C++ a while ago(using ogl libraries with win 32 api to be more precise), so I do see the difference in how much of the things are done in a decent amount of time (by one person).

If we are talking about speed… yeah, I guess you will not have Crysis any time soon in java at full details :). However, all the other stuff (mostly older OGL versions) goes pretty smooth. There are some ports for things done in C with OGL which are running at almost same speed (give or take 10%). So, unless you want some top benchmark performance – I am good with java/OGL performances, thank you very much 🙂

My current build for the java/OGL engine I am working on runs pretty smooth (that would be 30+ frame rate) on craptastic computer here at work, with an on-board Intel video card that is pretty much ancient. And I am not rendering just 3 vertices on the screen, so to speak 🙂 (well, of course I have some visual optimizations, you can’t have a visual engine without them, can you? no matter the language you are using, 3 million points on the screen will slow you down a LOT).

Of course, you could do same stuff in C# I guess (XNA rulz, and of course it saves time). But guess what – I have a really old version of windows here at work, and since I change computers a lot I can’t exactly afford to install every time .net or the stuff needed for the C# applications every goddamn time (not to mention, their examples crash on me every time, dunno why). On the other hand the java/JOGL stuff NEVER crashed. As in – nevar. Not once. Very stable stuff. And I love stable. Did I mention that? Oh, yeah – I love fast & stable. So that is why for now I will stick to my little JOGL project.

Nightwrath

I mean the various standard platform libraries, like J2ME/MIDP, but also things like certain aspects of the base object types. Having Integer, Float, Boolean, etc. be immutable is silly (why not use those as a pass-by-reference mechanism?) and I don’t like how you can’t resize arrays (but I realize Java probably has something like std::vector now) and how strings are immutable (but I realize that helps with pooling and that most uses of mutable strings are better served by StringBuilder anyway),

Still, it feels like much of the base class design is just legacy from when Java was a “theoretically-pure” language that was trying to appease academics, rather than trying to be an actual practical language that real programmers were going to use.

On the other hand, there’s plenty Java got right. Single inheritance with interface aggregation (which is the only sane way to deal with multiple inheritance on C++) and a single base class, class-as-object, reflection, etc. are all very nice for bridging the OO/imperative gap while maintaining strong typing (unlike e.g. Python, JavaScript, etc. which try to go way too far in providing an academically-pure OO in the name of “flexibility”), and recent developments have made Java a nice language for supporting the ad-hoc hacks that C++ has enjoyed in a cumbersome manner for a while (collections, iterators, weak references, etc.).

All that said, right now my favorite language concept is Vala – basically they took C and added all the good parts of C++ and C# while keeping it simple and syntactically-clean.

fluffy

Oh, and I almost like Java’s compile-time managed exceptions, although personally I’d prefer if the ‘throws’ list were generated implicitly and if the lack of catching were done as a link-level warning. Having it a compile error just encourages crap like 

try { … } catch (Exception e) {}

which is worse than useless. If it instead did a link-time warning like:

Warning: Exception NoSuchWidget thrown from someComplexClass.java:47 never caught

I think that people would be better about managing exceptions where they need to be managed. (I realize that this is also fundamentally incompatible with much of how Java’s link model works, but it’s not an intractable problem.)

fluffy

Um, fluffy, Java has always had an equivalent of std::Vector, in java.util.Vector (though there is a newer, better version of it called ArrayList). And I’d say managed exception suck, period. 🙂

Vala is indeed nice as a concept. But I fear that conservatism on the part of the programming community will keep it from seeing as much use as it deserves.

Felix

😉 Dacă ai timp poate vei testa https://wonderland.dev.java.net/ Te asigur că nu vei regreta.

… And, my english is too bad to be used in a conversation with a romanian. I like Your site; is nice and useful.

😉

suntonline

Funny you made the joke about Oracle’s law suit, I came across this article two years after you posted it, and after Googling the Oracle-Google suit discovered today’s the exact day that they start their billion dollar legal battle in court. It’ll be interesting to watch unfold…

And oh yeah…Java’s awesome!

NT