I'm looking to create a game in Java and would like it to work on Windows, Linux, and Mac. I'm pretty sure C# is a bad choice for this, and I don't have enough experience in C or C++. I want to stay away from Flash. Therefore, is Java a good choice for me? Mostly, I use C#, and think that Java is similar, so I assume it won't be that hard to learn. But is it fast enough? Is there a language more suited for my needs than Java?

  • 8
    Depends on what style of game you're looking to do. Depending on the style wanted it could be that HTML5 and some javascript would work for you, if not java. Nov 27, 2011 at 4:36
  • Oddlab sells Java based games, e.g. Tribal Trouble. You can see details of their engine at oddlabs.com/technology.php
    – user1249
    Nov 27, 2011 at 10:02
  • 5
    Minecraft is a great example of a cross-platform game written in Java. When our lad has his pals across for a serious Minecraft session they're playing it on OSX, Windows and Linux.
    – Kev
    Nov 27, 2011 at 14:35
  • Two years later, C# is now quite good for such things with the help of the Unity engine and/or Monogame, both of which also support iOS, Android, and WP8.
    – Magus
    Mar 14, 2014 at 23:12

5 Answers 5


Java is extremely suitable for writing cross-platform games. Main advantages:

  • Portability - In general, you can write a Java game and expect it to run unchanged on most platforms. It's probably the most portable option of any language - C/C++ is the other highly portable option but needs to be recompiled for each platform and in many cases libraries have platform specific features that limit portability.
  • Performance - Java code, if written well, will perform pretty much as well as any other language, including C/C++. The JVM JIT compiler is extremely good. You can write a top quality, successful game in Java (Minecraft, for example).
  • Libraries - there are a huge range of libraries available for Java that cover almost every feature you could want in games, from networking to graphics to sound to AI. Most Java libraries are open source.

The main decision you will have to take is what GUI framework you are going to use. There are quite a few different options but the most prominent ones are:

  • jMonkeyEngine - fully fledged 3D engine. If you want to make a 3D game this is probably your best choice - contains lots of game engine features such as scene graphs, terrain generation etc.
  • LWJGL - a more low-level library with direct access to OpenGL. Likely to appeal to you if you want maximum performance and don't mind writing a lot of your engine from scratch.
  • Swing - has the advantage of being extremely portable and is included in the Java runtime so doesn't need an extra dependency. It's good for non-graphically-intensive 2D games (strategy games, card games etc.)
  • Slick - a 2D game library based on LWJGL. Probably good if you want to write a 2D game but still need good graphics performance (shoot-em-ups, scrolling platform games etc.)
  • JavaFX - designed for rich internet applications, roughly like Flash. Has a lot of neat features that would be good for games although I haven't seen it used much yet. JavaFX 2.0 in particular is looking quite promising.

The main disadvantages for Java for gaming are really around the "edge cases" that probably won't affect you but are relevant for some classes of game:

  • 3D engine availability - although the tools and engines listed above are good, they still aren't quite up to the level of C/C++ engines like the Unreal Engine used by professional game companies. So Java is possibly not goingto be your first choice if you are are trying to develop a major FPS with a multi-million budget - C/C++ still wins out here.
  • GC latency Java garbage collection is overall a huge benefit, but it can cause slight pauses when GC cycles happen. This is getting much better with new low-latency JVMs, but still can be an issue for games with very low latency requirements (first person shooters perhaps). A workaround is to use low latency libraries like http://javolution.org/, however these seem to be targetted more at high frequency trading or realtime systems rather than games.
  • Lack of ability to exploit low level optimisations - while the Java JIT compiler is incredibly good, it still enforces some constraints that you can't avoid (bounds checking on arrays, for example). If you really need to get native machine-code level access to optimise this kind of thing away, then again you will probably prefer C/C++ over Java.

Note that there are also a few deployment options to consider:

  • Applet - runs in a browser, very convenient for users, however applets are rather restricted in what they can do for security reasons. Note that you can sign applets to get extra security privileges, although this will cause a slightly scary prompt for most users.
  • Java Web Start - better for more sophisticated games that need a full local download and also need to access local system resources. It also works in a pretty platform-independent way. Probably the best route for a medium-sized game or something that needs to escape applet security restrictions.
  • Installer download - You can write an installer for a Java game just as you could for any other language. It's a bit more work to configure and test of course, since installers tend to have some platform-specific features.
  • Web - you could write a HTML5 web application and make use of the strength of Java purely on the server side. Worth considering for a multiplayer web game.

Finally, it's also worth considering some of the other JVM languages - these have all the benefits of the Java platform listed above, but some consider them to be better languages than Java itself. Scala, Clojure and Groovy would be the most prominent ones, and they can all make use of the Java tools and libraries listed above.

  • 1
    JWS doesn't really add much over applets other than separating your app from the browser. In both cases I think you'll want to sign your code if you're using an OpenGL library. Nov 27, 2011 at 8:11
  • 2
    I'd say that local system access is a really big "much" over applet restrictions for many serious games, especially multiplayer. HTML5 is neat, but it's still a wee babby with spotty support and important bits like GL and Sockets turned off on many browsers, plus the audio isn't yet well suited for game use. Nov 27, 2011 at 18:28
  • 1
    @PatrickHughes, if you want that local system access from JWS without big scary dialogs you'll need to sign your code - and a signed applet will usually have local system access too. Nov 27, 2011 at 22:54
  • You can also use Inno Setup to distribute your Java games. Nov 27, 2011 at 23:32
  • 1
    You can add LIBGDX to the list of packages that help you in writing your own engine; it has setups and JNI optimizations for various platforms and even Android and down to OpenGL ES. Feb 27, 2012 at 18:42

Minecraft and Blocks that Matter are both built in Java, so yes it's plenty good for making games. The main issue you're going to run into while using Java is porting to mobile platforms if you choose to go that route and write a native app. Android is a kind of frankensteined Java SE with a separate library. RIM's Blackberry uses Java ME. iOS can in theory be programmed with Java though Objective-C would likely be a better choice for that platform.

Java is quite similar to C#. I often find C# code understandable despite only knowing Java. They do have a different design philosophy but as far as being widely deployable with minimal hassle both fit the bill. C# isn't a terrible choice for games by any stretch either though your mobile deployment will be harder and deploying to non-windows platforms will be more time consuming or difficult depending on what specific external libraries and so forth you wind up using.

  • 1
    Java on mobile : compile once, debug everywhere :'( .
    – deadalnix
    Feb 27, 2012 at 10:37

The most obvious and least resistant way is to use HTML5+javascript combo. Any application or game made using this will run on almost every device and browser.

Advantage :- You will need zero configuration for making your game run on various platforms and devices.

NOTE:- I have seen few games that are build using the above said technologies but they were smaller in stature. But, I suppose if one can make butter out of milk then cheese is not impossible


You can use Scala and Scheme Bigloo on Eclipse to use JVM for stressed code or parrallel action inside your Java game.

With Pattern Design and UML2, you can also secure code with OCL, all is in Topcased.org .

Mastering those tools take time, but they are the Java's background, the base which will push you at the top.


Short answer: no.

Java do not generates a binary executable but only bytecode as C# does ( CLI ), and this is not a good thing for serious business in "opened environments" for two main reasons:

  • the probability to get trapped in reverse engeneering are very high, especially with old and really well knowed languages like Java
  • you are not in full control over the machine performances, in the case of Java the JVM plays a big role taking the full control.

Of course every language has its own libraries but due to the great amount of them for each and every language this is not a real problem and i don't think is the purpose of this topic.

Maybe at a professional level you can find something that can break the rule like a dev-Kit that can translate all C# statements into assembly code for a real world machine, but if this kind of approach it's not in the cards you are pratically forced to consider only the C and the C++ for your development when you aim to sell your product in an open environment.

The things are a little bit different for the mobile devices because they are "closed environment" even Android is pratically closed considering the fact that the source of the real world ROMs are not usually available to the public, Android may be considered opensource but the 99% of the ROMs on actuals devices aren't. In this cases you can't argue too much, everything is already set for you and every platform has its own language like everybody knows.

In the end if you are going to sell this products in an opened environments i can only suggest languages that can produce compiled and binary/assembly code, in closed environments the decision is tipically more easy to do for different reasons.

  • 7
    You seem to believe that compiled binaries are harder to reverse engineer than bytecode binaries. There may be a little truth in that, but not a lot. In fact probably more people can work with x86 and x64 disassembler than with CLI or Java bytecode, and you'd be amazed how helpful a tool like IDA Pro can be (disclaimer - I haven't used it since the free version quite a few years ago - it's probably even easier now). An obfuscated bytecode file may even be harder to reverse engineer and, in any case, most people will have little reason to care.
    – user8709
    Nov 27, 2011 at 7:57
  • 2
    Why little reason to care? Well, how many people write their own low-level proprietary game engines? And even if you do that, what are the odds that someone would rather steal your one (needing reverse engineering, lacking any kind of documentation, etc - lots of time wasted there, no matter what the development language is) rather than legally use a well-documented free open-source engine? Piracy of the full program is a far more likely real concern than reverse engineering to steal code ideas, and pirates don't seem the slightest bit deterred by native compiled code.
    – user8709
    Nov 27, 2011 at 8:06
  • 1
    On levels of abstraction, JVM instructions are extremely low level - not precisely as in hardware, but basically just as far removed from the application layer abstraction. Where the layers of abstraction count is in the standard Java libraries, meaning there really are few layers between the platform and the final application. Except that normally happens in C and C++ anyway (why reinvent libpng etc) - most people will use common libraries which effectively form a set of widely known platforms, and good reverse-engineering tools can recognise them.
    – user8709
    Nov 27, 2011 at 10:40
  • 3
    To satisfy the requirements all code would have to ship on FPGA and encased in epoxy. Surprise, even black-box chip packages can and are reverse engineered all the time. Then even mighty giants like Intel introduce bugs in their CPU packages so your epoxy embedded, hardware black box is still going to suffer from exposure to hardware libraries. Finally the call to security by obscurity, that doesn't work. Reductio ad absurdum, I know, but so is the original answer. Nov 27, 2011 at 18:20
  • 3
    Unfortunately I don't have the enough reputation to downvote you. All of your arguments are failed. There are people out there decoding, decompiling and hacking games produced in C, C++ or whatever language, so being a binary package won't provide much additional security. Further, if if the OP is concerned about this, there are a lot of very good java obfuscators out there. About full control of machine performance, most of C and C++ programmers don't have this either, just write good code and the compiler will optimizewhat is needed. And even if that is a problem, you could use JNI or JNA. Jan 18, 2012 at 1:38

Not the answer you're looking for? Browse other questions tagged or ask your own question.