I want to make a multiplayer browser-based game. The nice thing about using an applet is that I can make the client and the server in the same language (java/closure/scala/etc). I know there's html5 and javascript, but server side javascript isn't as mature as the jvm platform and browser support is still kind of flaky.

Applets don't seem to be widely used (except for Runescape), but is there a reason they're unsuitable or is it just because of the bad reputation they developed in their infancy?

  • 1
    \$\begingroup\$ Maybe because few people do web games in Java, and prefer Flash? \$\endgroup\$ Mar 14, 2011 at 18:39
  • \$\begingroup\$ Java is simply not as readily available in browsers anymore nowadays (compared to Flash, or by all means javascript), and there's a good chance your target audience won't have it installed. You can still use Java on the server side all you want though, regardless of client side tech, I don't understand the argument that "server side javascript isn't as mature as the jvm platform". \$\endgroup\$
    – falstro
    Mar 14, 2011 at 20:38

5 Answers 5


They are obviously not unsuited for it, as demonstrated by RuneScape and Minecraft and other smaller Java applet games. There are also libraries for hardware-accelerated 3D graphics (LWJGL, JOGL). It's just not a popular language in the game development community.

You do have to consider your supported platforms though. Windows and Linux have great Java plugins, Mac has a decent one (only works at full speed in Safari in my experience), but obviously platforms such as the iPad and Google's Chrome OS would be completely missed because they do not, and probably will not ever, have the Java VM on them.

  • \$\begingroup\$ Additionally you have to think about your target market - the minecraft players obviously can handle going to java.com and installing it, but lots of the "internet explorer crowd" might not be. \$\endgroup\$ Mar 14, 2011 at 14:08
  • 1
    \$\begingroup\$ However, Minecraft is made well in that those users can simply download the executable version, which includes the JRE and doesn't need any such installation; it Just Works™. \$\endgroup\$
    – Ricket
    Mar 14, 2011 at 14:20
  • 2
    \$\begingroup\$ I think, that java is great solution how to access gpu in browser without forcing user to install something (80-85% users has java installed ... including explorer noobs too :)) \$\endgroup\$
    – Notabene
    Mar 14, 2011 at 14:41

I use Java to write games and I've used C++ to write games and have found Java to be fine so long as you remain mindful of what Java's strengths and weaknesses are. The big two advantages for me, programming in Java are speed of development and deployability/portability. Compile times are much faster than in VC++ (can't speak for XCode or Clang yet) which means I can iron out problems much quicker. Also, as Eclipse is compiling constantly, I make fewer typo type errors. I've never written a piece of C++ code that 'just works' on another system or compiler. In Java, this is the norm.

On the other hand, Java has some major draw backs. Efficiency is often sited as a reason not to use Java but I've found that as long as you code in a certain way, Java can perform quite well. The trouble is, the certain way you have to code goes against what a lot of Java folk would consider good design.
At Java's heart is the 'garbage collector', it's memory management system. When writing efficient code, you want to avoid making dynamic allocations every frame in any language and this is particularly true of Java. If you set the garbage collector off due to sloppy new'ing then you can kiss smooth frame rates good bye. Secondly (and most annoyingly) Java does not support 1st class user data types. Every user data type in Java is instantiated essentially as a pointer to a class, allocated on the heap. This is awful for cache concurrency that you can't have things like an array of Vector3 objects and have those concurrent in memory - you can have an array of Vector3 pointers but that's not the same thing at all. Generally you have to use offsets into large arrays of primitive types instead.


Times have changed. To state the obvious, and because there is currently no "correct" answer to this question: you should not use a Java applet to build your game because modern web browsers no longer support Java applets. Support for Java applets was removed because of security reasons.

  • Chrome removed their support around 2014.
  • Safari support for it was removed around 2018 and 2020.
  • Microsoft Edge has never supported Java.
  • Firefox dropped the support for it around 2016.
  • Other browsers use are marginal according to this (screen shot when this was checked), so you wouldn't want to support only one of those.
  • The <applet> HTML tag used to insert an applet on a page is deprecated in HTML5 and no longer supported by most recent browsers.

You can still use Java to build games: AFAIK, there are multiple mature game development frameworks/libraries/engines available; however the way you'll distribute your game will be different than using an applet. If you wish to distribute your game through a web browser, the way to go nowadays is typically by using JavaScript.


Nothing wrong with Java applets for a web game. I wrote an open source roguelike game (Tyrant) in Java and it works very well as an applet.

Some big plus points of Java in my experience:

  • Portability is excellent - given the complexity of Tyrant, it was pretty impressive that I managed to get exactly the same compiled code to run well on Windows, Mac and Linux.

  • You don't have to worry about browser quirks.

  • With a bit of cleverness, you can make the same code run both as an applet or as a standalone desktop application

  • Performance is great assuming a modern JVM.

  • All the usual plus points of Java in terms of great array of open source libraries/APIs etc.

Just be aware of the following:

  • You'll need to sign your applet / get privileged permissions if you want to do things like store data on the local filesystem or access native libraries. This can be a barrier to some users.

  • Startup time tends to be a bit slower than Flash or JavaScript. On the other hand, performance is better once the JVM is up and running......

  • Java is a garbage collected language, so it does have very slight GC pauses on occasion. Not really a problem for casual / roleplaying / strategy games, but might be an issue for high performance 3D FPS titles where you're trying to maintain a constant jitter-free 120 FPs framerate......


If you're planning for the game to be freeware or are prepared to handle making money from it all by yourself, Java's fine. However, it doesn't have an established, wide-spread game sponsorship model like Flash does, so making cash would be a bit harder.

  • \$\begingroup\$ Do I smell an opportunity? :) \$\endgroup\$
    – Ricket
    Mar 14, 2011 at 17:20
  • \$\begingroup\$ I'm not sure if the sponsorship model presents a good deal for creators. It's better to sell your work for a reasonable price than take a pittance from a portal site who make a pittance from the advertising. \$\endgroup\$
    – Luther
    Mar 14, 2011 at 18:51
  • \$\begingroup\$ Luther: true enough. Just because a model is established doesn't mean it's the best one. \$\endgroup\$ Mar 16, 2011 at 14:01

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .