Why isn't Java more widely used for game development?

  • I'm not a game developer or anything, but I know that Java is not very widely used for game development. Java should be fast enough for most games, so where's the catch? I can think of some reasons:

    • Lack of game developers with expertice in Java
    • Lack of good game development frameworks
    • Programmers don't want to accept Java as a games programming language. Most only accept C++ as that?
    • No support for game consoles (though the PC market still exists)

    It could of course be something else. Could someone who knows the business better than me explain why Java isn't getting momentum when it comes to game development?

    And now wait for all of the "Java is slow, C++ is fast" answers that really only touch the surface of the issue in an overly broad and completely correct way. Be aware that people answering this way are almost certainly not professional game developers.

    In fact, Java _is_ used for game development; i.e. in the mobile market. Java ME, Android.

    Meant to say "*not* completely correct way" above =D

    Why should it be used? What does Java offer a game developer, that the more widely used languages don't have? Java provides an enourmously rich ecosystems to business application developers, that outweighs its shortcomings as a language, but when it comes to game development, the Java platform offers little tools compared to a number of alternatives.

    Interestingly, Minecraft is Java based.

    As I noted below in comments, its more a matter of runtime access across platforms that inhibits managed/jvm based games from becoming more mainstream. Three completely seperate codebases makes little sense even if in isolation the managed/jvm code accomplishes as much, nearly as efficiently, and with far less hand crafted code.

    Java is HIGH LEVEL, c is LOW LEVEL. How can anyone possibly make this question more complicated?? It's just that simple.

    Ed S - I'm guessing you are **not** a "professional game developer"?!

    @Peter Taylor: I think even the fact, that there is a list of all successful Java games shows, how few there are. @Uri: What exactly is interesting about that?

    @back2dos, where did anyone say that it was an exhaustive list?

    To whoever has down voted all of the posts that say that Java doesn't have the same performance as C/C++, last time I checked; Java uses a Stop-The-World garbage collector. This is fine for Business applications, but gamers *will* get annoyed if their game stops temporarily.

    @Joe Blow: I think he guesses you're not that either

    @dan_waterworth Garbage collection can be tuned for the application profile and collection pauses can be reduced (although, I am guessing few develops opt for or are even aware of tuning the GC). By default it is tuned for throughput and smallish allocations. Eg small server apps.

    Magicka is also written in C#.

    To me Java adds very little value to game development. For performance code you want to be in control and not battling with garbage collector :o) C or C++ (if used sanely) just rule in this domain. For higher level game code you are usually better off with other offerings because of better C/C++ binding: UnrealScript, Lua, Python, etc. Otherwise Java would be quite usable in this domain (UnrealScript is actually quite Java-ish).

    @JoeBlow: Why is it better to use a low-level language for game programming? Is that still true today? Maybe that's necessary if you are making NES cartridges, but not if you're targeting, say, and iPhone. (I don't know, but all discussion I see takes it as *clearly true*, without ever explaining why.)

    @Coder Looks like the C++ code was heavily optimized, but the Java code was not. So it's an invalid comparison.

    One must distinguish between the language (Java) and the way (JVM) a program written in this language is executed by a computer. On the one hand programs written in Java can be compiled (by AOT compilers like Excelsior JET) and executed without the JVM. On the other hand the JVM can be used to execute programs written in languages other than Java, e.g. Groovy (which provides advanced features like operator overloading).

    People that say "Java is slow" are just co-signing an old blog while java was in its infancy. I'm already writing a 3D game in Java/JOGL and the performance is wonderful. To end the debate this is the ultimate decider today: "If you write crappy code, you get crappy performance."

    Bastion is partially implemented using MonoGame (that is, C#). That's how it runs on Linux, and it runs pretty well. If it can be done with C#/Mono, it probably can be done with Java, especially delegating low-level graphics stuff to the appropriate libraries.

    @JoeBlow LOW-LEVEL actually works against the development of interesting and complex game logic. Low-level graphics do benefit from raw low-level performance, yes; that's why you delegate that to libraries (or implement that parts in C or C++). But game logic? Give me a high-level language, please!

    Okay, I know the business **extremely* well, having been in it for 25 years. I also know Java in games *extremely* all having been Sun's Java Game technical evangelist. And you are dead, spot on. Most of the people "correcting" you are horribly misinformed. I'll post more on that in a full post.

    @Uri: So was the new Sim City and look how that turned out.

  • Uri

    Uri Correct answer

    10 years ago

    Several reasons:

    • In the old days, you needed "direct access" for performance and UI. This predates VM languages like Java and C#.
    • Most consoles (e.g., 360, PS3) do not have a JVM, so you cannot reuse code from the PC version. It is much easier to compile C++ code to support various devices.
    • Most mainstream game engines (e.g., Unreal) have C++ bindings. There are some Java connectors (e.g., for OpenGL) but nothing like it.
    • For PC gaming, DirectX doesn't really have strong Java support (if at all).
    • Web based games run in JavaScript or Flash. You could write them in Java though using things like GWT.
    • The iPhone runs an Objective-C variant.

    Java is primarily used in Android games these days, simply because it's the primary language for that platform.

    +1 "Most consoles (e.g., 360, PS3) do not have a JVM, so you cannot reuse code from the PC version. It is much easier to compile C++ code to support various devices" If the device doesn't have the runtime, you won't see games developed based on that unavailable runtime. Xbox 360 and Windows phone have managed .Net runtimes, so game development using them is possible, and likely a growing trend. However, because the runtime isn't on the other major platforms (PS3, and to a much lesser extent, Wii), its hard to justify a completely seperate codebase. It really is not a performance issue at all.

    @JustinC: That's a good point. I haven't realized that the 360 had a .NET runtime, I thought that it predates the popularity of that platform.

    It's called XNA, which is currently subset of the .Net 2.0 framework. There are some other interesting frameworks in the wild: MonoXNA, MonoTouch, and XnaTouch among others.

    A JVM for consoles can be included on the game disc. I don't see the problem there.

    Predictability of performance is not possible with a JVM.

    Very good points. However, I'd add the fact that the GC can cause unpredictable pauses/load . If this isn't a problem for server apps, it is for a real time game. This is for instance visible in minecraft.

    Best answer IMHO. One thing I'd like to add is that it's much harder to keep memory footprint low in Java than it is in C++. When there's a lot of data invovled, JVM just bloats. Coding your way out of that can be very hard.

    @WTP Technically: Yes, one could. Practically you'd have to port it to the platform, optimize it for the platform and and pay license fees (or deal with GPL) for being worth it Java would have to provide notable benefits.

    Also, programming OpenGL in Java is a big pain. Java 3D is still full of errors and too complicated. M3G available on J2ME devices is a joke. Even on Android people go for C when implementing OpenGL games.

    @Klaim It's also not possible with `malloc` or `new`, so if that's a concern you're going to implement pooling no matter what. Unrelated to that point, a big issue with Java is that it doesn't support value types, unlike C#.

License under CC-BY-SA with attribution

Content dated before 6/26/2020 9:53 AM