7 ms·

The amount of vitriol Java receives in the game development space is rather strong. However, whenever people dismiss Java as being a bad language, I can't help

The amount of vitriol Java receives in the game development space is rather strong. However, whenever people dismiss Java as being a bad language, I can't help but think of Minecraft. Yes, it's one of the few mainstream titles where Java has been successfully applied, but I believe Minecraft's success was specifically because it was written in Java. With no JVM, there would have been no Minecraft mods at the level of flexibility that Forge provides, and the game would probably have stagnated in comparison with the sheer amount of community content from the past ten years that's available. Being able to use libraries like ASM that allow you to transform the compiled bytecode in radical ways were possible only because Minecraft targeted a virtual machine. The incredible thing was that this was in spite of the obfuscation Mojang applied to the compiled source. If it was possible to create a flexible mod system at all thanks to the JVM, people were just too motivated for any deterrence to stop them. For the people who say that Minecraft should have been written in C++ or something from the start, because Java is a mediocre programming language, there's Bedrock Edition. Nobody I know cares about it enough to play it. For all its bloat and performance issues, the benefits of the JVM were simply too convincing.

slver 6y ago
> The amount of vitriol Java receives in the game development space is rather strong. Java is a language with mandatory GC, tiny objects scattered around the heap (poor locality), and no value types or low-level memory access. This makes it very poor for games (you know, other very basic ones). But they're rapidly addressing these concerns.
- chii 6y ago
  > no value types or low-level memory access. i dont think you need value types at all, and you can simulate it by using byte buffers with an abstraction on top of it. After all, what's the difference between value types and a byte array? As for things like low level memory access - you also don't need that in most cases. Graphics libraries will give you enough access. And for any other case, you can always JNI into native code, or call any existing system calls or libraries. Interop between java and native is not that bad (cumbersome for sure, but still possible). The only reason java gets poor performance is the coder doing java is too used to producing garbage (or is too inexperienced to write high performance java code). you can easily avoid most performance problems in memory by pre-allocating and reusing memory by pooling. These techniques are already commonly employed in C.
  - saagarjha 6y ago
    Why even use a high language at all when you can just write the assembly directly? Clearly you can write "Java" that is patently unsafe in an effort to eke out some performance, but this is not what most people would consider reasonable or desirable. When writing Java, you almost always want to go with the flow, and that at the moment means creating objects. The general fix for this is to have good abstractions for places where heap allocations can be elided, not dropping down to lower-level primitives in an ad-hoc way.
    - chii 6y ago
      > Why even use a high language at all for the parts that don't need high performance. And for leveraging existing libraries, if any are suitable.
  - slver 6y ago
    > i dont think you need value types at all, and you can simulate it by using byte buffers with an abstraction on top of it. After all, what's the difference between value types and a byte array? The difference is a bit like coding in Java vs coding in assembler (more below in an example). > The only reason java gets poor performance is the coder doing java is too used to producing garbage (or is too inexperienced to write high performance java code). Read about Entity Component Systems, the leading architecture of high-performance game engines these days. To do this in Java, with the implied memory locality, would basically mean storing your entire game state in bytebuffers, and constantly unpacking and packing them to do any operation on them. And when you unpack them if you unpack them to a random object in heap, you negate the entire purpose of the locality of a bytebuffer. So you somehow need to do the job raw, reading everything inline and putting it back inline, so you can stay on the stack. I also doubt that the get/put calls you'd need to do to get/set every number would be free. So performance would probably end up quite terrible. > you can easily avoid most performance problems in memory by pre-allocating and reusing memory by pooling. If you make an object pool in Java you'll save on memory alloc/dealloc. You won't achieve memory locality, so your code will be much slower than languages where you can do that.
    - 6y ago
- mrighele 6y ago
  This is true for JS too, but I never hear as much hate for that language. Also there are classes of games for which the latency introduced by a GC may not be that much relevant (e.g. strategy or simulation games).
  - slver 6y ago
    > This is true for JS too, but I never hear as much hate for that language. Really? https://www.google.com/search?q=JavaScript+is+the+worst+language https://www.google.com/search?q=JavaScript+is+the+worst+lang... If it exists, some people hate it. If it's popular, most people hate it. It's a universal law. /s Anyway, you never hear "JS is not suitable for high-end games" because with JS that's kind of self-evident. While with Java, some people don't know enough to realize that. > Also there are classes of games for which the latency introduced by a GC may not be that much relevant (e.g. strategy or simulation games). Strategy/simulation games can get quite big/complex. Keep in mind you're not just modeling the units, but also the terrain the various particle effects and so on. You can definitely pull off something like StarCraft 1. But people want games to match the capabilities of their hardware, not that of a Pentium from the 90s. And performance remains crucial on mobile. I.e. you may get the game going, but it'll suck your battery empty in record time.
  - Ashanmaril 6y ago
    You probably don't hear as much hate for JS as a games language because it's not even on the table for a consideration when making a moderately intensive game
- wing-_-nuts 6y ago
  >But they're rapidly addressing these concerns. Expand?
  - slver 6y ago
    Project Panama (Foreign Memory Access): https://medium.com/@youngty1997/jdk-14-foreign-memory-access-api-overview-70951fe221c9 https://medium.com/@youngty1997/jdk-14-foreign-memory-access... Project Valhalla (Inline Classes aka Value Types): https://dzone.com/articles/project-valhalla-fast-and-furious-java https://dzone.com/articles/project-valhalla-fast-and-furious... The links I picked are a bit random but they'll get you going with the basics.
- kaba0 6y ago
  For the great majority of your code base, it doesn’t matter (look at scripting languages inside game engines), and for the performance critical parts, you have excellent profilers and can easily pinpoint which function creates too much garbage and can write that part in an imperative way with arrays and that’s it. It will run plenty fast. Especially now with ZGC, not even tiny freezes should happen.
donatj 6y ago
> For the people who say that Minecraft should have been written in C++ […] there's Bedrock Edition. Nobody I know cares about it enough to play it. Been playing for just under ten years, everyone I know plays Bedrock these days. I built and manage a very popular tool / Minecraft community and while I don’t have actual numbers, my general sense is the majority of players run either console or mobile Minecraft - all of which are Bedrock at this point. If you don’t care about modding or particularly complex redstone, I don’t know why you wouldn’t run Bedrock. It’s far more stable, reliable and performant. My laptops fans rarely come on in Bedrock but never shut off in Java. In my eyes Java is the public prototype / feature target and Bedrock the actual product.
- scaladev 6y ago
  >I don’t know why you wouldn’t run Bedrock Because not everybody runs Windows? I don't consider mobile and console platforms as gaming, but that's just my biases.
  - Twirrim 6y ago
    > Because not everybody runs Windows? I don't consider mobile and console platforms as gaming, but that's just my biases. Most PC gamers use Windows, consoles or devices. The non-Windows gaming market is very small. While I prefer Java edition, my kid much prefers Bedrock, because it has the main killer feature of being able to share a world directly with friends. Anyone that's an XBox Live friend can see when they're playing on-line, and join the world. No need to set up a realm, run my own server online somewhere, or punch a hole through the firewall to the minecraft server at home etc.
  - donatj 6y ago
    I actually personally run the Bedrock Android version on my Mac with a launcher. It’s a little temperamental but still preferable to Java Edition in my eyes. I mostly play on Windows and Xbox however. - https://mcpelauncher.readthedocs.io/en/latest/ https://mcpelauncher.readthedocs.io/en/latest/ - it’s out of date but they link a fork that works.
  - TrickyRick 6y ago
georgeecollins 6y ago
>> The amount of vitriol Java receives in the game development space is rather strong. I think this is because of the way it handles memory. It's like the clunkiness of C++ without the power to optimize. Also, compared to python it is fast, but not compared to C or Rust. That said, for 99% of applications the Java garbage collector is safe and tends to produce reliable code. The article is right in that Java is an extremely useful language with good tools. Games are an edge case.
- kaba0 6y ago
  > Also, compared to python it is fast, but not compared to C or Rust. It is comparably fast. Much more close to them than to python.
correct_horse 6y ago
I think the Minecraft mod scene happened because java is easier to deobfuscate than C++. JVM bytecode doesn't have as many opcodes as x86_64 and JVM bytecode's opcodes are on average simpler. I suspect that modding a new unobfuscated game written in C++ that contains debugging symbols would be far easier than modding Minecraft was before obfuscation maps were available. But games rarely ship like this, since they would be easy to pirate.
npteljes 6y ago
Minecraft is not successful because of its programming language, it's successful despite the questionable choice of its programming language. Games can be fine and successful withouth being top-notch software, they need to be enjoyable, not performant. Cities:Skylines is also successful, and with decent hardware you get like 40 fps. Again, not its hardware efficiency made it popular. Regarding modding, I think if the game is successful, then there will be at least a small handful of people that write a modding interface for others.
strictfp 6y ago
Bedrock is by far the most popular version of Minecraft. It's the version used on all handhelds and consoles.
Rhedox 6y ago
Minecraft is also a prime example for why Java is bad for game development. The GC is constantly overworked because Java has to allocate immutable vector and matrix classes on the heap. In other languages (like C# for example) you'd make that a struct and enjoy value type semantics and stack allocation (in most cases).

slver 6y ago

> The amount of vitriol Java receives in the game development space is rather strong. Java is a language with mandatory GC, tiny objects scattered around the heap (poor locality), and no value types or low-level memory access. This makes it very poor for games (you know, other very basic ones). But they're rapidly addressing these concerns.

chii 6y ago
> no value types or low-level memory access. i dont think you need value types at all, and you can simulate it by using byte buffers with an abstraction on top of it. After all, what's the difference between value types and a byte array? As for things like low level memory access - you also don't need that in most cases. Graphics libraries will give you enough access. And for any other case, you can always JNI into native code, or call any existing system calls or libraries. Interop between java and native is not that bad (cumbersome for sure, but still possible). The only reason java gets poor performance is the coder doing java is too used to producing garbage (or is too inexperienced to write high performance java code). you can easily avoid most performance problems in memory by pre-allocating and reusing memory by pooling. These techniques are already commonly employed in C.
- saagarjha 6y ago
  Why even use a high language at all when you can just write the assembly directly? Clearly you can write "Java" that is patently unsafe in an effort to eke out some performance, but this is not what most people would consider reasonable or desirable. When writing Java, you almost always want to go with the flow, and that at the moment means creating objects. The general fix for this is to have good abstractions for places where heap allocations can be elided, not dropping down to lower-level primitives in an ad-hoc way.
  - chii 6y ago
    > Why even use a high language at all for the parts that don't need high performance. And for leveraging existing libraries, if any are suitable.
- slver 6y ago
  > i dont think you need value types at all, and you can simulate it by using byte buffers with an abstraction on top of it. After all, what's the difference between value types and a byte array? The difference is a bit like coding in Java vs coding in assembler (more below in an example). > The only reason java gets poor performance is the coder doing java is too used to producing garbage (or is too inexperienced to write high performance java code). Read about Entity Component Systems, the leading architecture of high-performance game engines these days. To do this in Java, with the implied memory locality, would basically mean storing your entire game state in bytebuffers, and constantly unpacking and packing them to do any operation on them. And when you unpack them if you unpack them to a random object in heap, you negate the entire purpose of the locality of a bytebuffer. So you somehow need to do the job raw, reading everything inline and putting it back inline, so you can stay on the stack. I also doubt that the get/put calls you'd need to do to get/set every number would be free. So performance would probably end up quite terrible. > you can easily avoid most performance problems in memory by pre-allocating and reusing memory by pooling. If you make an object pool in Java you'll save on memory alloc/dealloc. You won't achieve memory locality, so your code will be much slower than languages where you can do that.
  - 6y ago
mrighele 6y ago
This is true for JS too, but I never hear as much hate for that language. Also there are classes of games for which the latency introduced by a GC may not be that much relevant (e.g. strategy or simulation games).
- slver 6y ago
  > This is true for JS too, but I never hear as much hate for that language. Really? https://www.google.com/search?q=JavaScript+is+the+worst+language https://www.google.com/search?q=JavaScript+is+the+worst+lang... If it exists, some people hate it. If it's popular, most people hate it. It's a universal law. /s Anyway, you never hear "JS is not suitable for high-end games" because with JS that's kind of self-evident. While with Java, some people don't know enough to realize that. > Also there are classes of games for which the latency introduced by a GC may not be that much relevant (e.g. strategy or simulation games). Strategy/simulation games can get quite big/complex. Keep in mind you're not just modeling the units, but also the terrain the various particle effects and so on. You can definitely pull off something like StarCraft 1. But people want games to match the capabilities of their hardware, not that of a Pentium from the 90s. And performance remains crucial on mobile. I.e. you may get the game going, but it'll suck your battery empty in record time.
- Ashanmaril 6y ago
  You probably don't hear as much hate for JS as a games language because it's not even on the table for a consideration when making a moderately intensive game
wing-_-nuts 6y ago
>But they're rapidly addressing these concerns. Expand?
- slver 6y ago
  Project Panama (Foreign Memory Access): https://medium.com/@youngty1997/jdk-14-foreign-memory-access-api-overview-70951fe221c9 https://medium.com/@youngty1997/jdk-14-foreign-memory-access... Project Valhalla (Inline Classes aka Value Types): https://dzone.com/articles/project-valhalla-fast-and-furious-java https://dzone.com/articles/project-valhalla-fast-and-furious... The links I picked are a bit random but they'll get you going with the basics.
kaba0 6y ago
For the great majority of your code base, it doesn’t matter (look at scripting languages inside game engines), and for the performance critical parts, you have excellent profilers and can easily pinpoint which function creates too much garbage and can write that part in an imperative way with arrays and that’s it. It will run plenty fast. Especially now with ZGC, not even tiny freezes should happen.

donatj 6y ago

> For the people who say that Minecraft should have been written in C++ […] there's Bedrock Edition. Nobody I know cares about it enough to play it. Been playing for just under ten years, everyone I know plays Bedrock these days. I built and manage a very popular tool / Minecraft community and while I don’t have actual numbers, my general sense is the majority of players run either console or mobile Minecraft - all of which are Bedrock at this point. If you don’t care about modding or particularly complex redstone, I don’t know why you wouldn’t run Bedrock. It’s far more stable, reliable and performant. My laptops fans rarely come on in Bedrock but never shut off in Java. In my eyes Java is the public prototype / feature target and Bedrock the actual product.

scaladev 6y ago
>I don’t know why you wouldn’t run Bedrock Because not everybody runs Windows? I don't consider mobile and console platforms as gaming, but that's just my biases.
- Twirrim 6y ago
  > Because not everybody runs Windows? I don't consider mobile and console platforms as gaming, but that's just my biases. Most PC gamers use Windows, consoles or devices. The non-Windows gaming market is very small. While I prefer Java edition, my kid much prefers Bedrock, because it has the main killer feature of being able to share a world directly with friends. Anyone that's an XBox Live friend can see when they're playing on-line, and join the world. No need to set up a realm, run my own server online somewhere, or punch a hole through the firewall to the minecraft server at home etc.
- donatj 6y ago
  I actually personally run the Bedrock Android version on my Mac with a launcher. It’s a little temperamental but still preferable to Java Edition in my eyes. I mostly play on Windows and Xbox however. - https://mcpelauncher.readthedocs.io/en/latest/ https://mcpelauncher.readthedocs.io/en/latest/ - it’s out of date but they link a fork that works.
- TrickyRick 6y ago

georgeecollins 6y ago

>> The amount of vitriol Java receives in the game development space is rather strong. I think this is because of the way it handles memory. It's like the clunkiness of C++ without the power to optimize. Also, compared to python it is fast, but not compared to C or Rust. That said, for 99% of applications the Java garbage collector is safe and tends to produce reliable code. The article is right in that Java is an extremely useful language with good tools. Games are an edge case.

kaba0 6y ago
> Also, compared to python it is fast, but not compared to C or Rust. It is comparably fast. Much more close to them than to python.

correct_horse 6y ago

I think the Minecraft mod scene happened because java is easier to deobfuscate than C++. JVM bytecode doesn't have as many opcodes as x86_64 and JVM bytecode's opcodes are on average simpler. I suspect that modding a new unobfuscated game written in C++ that contains debugging symbols would be far easier than modding Minecraft was before obfuscation maps were available. But games rarely ship like this, since they would be easy to pirate.

npteljes 6y ago

Minecraft is not successful because of its programming language, it's successful despite the questionable choice of its programming language. Games can be fine and successful withouth being top-notch software, they need to be enjoyable, not performant. Cities:Skylines is also successful, and with decent hardware you get like 40 fps. Again, not its hardware efficiency made it popular. Regarding modding, I think if the game is successful, then there will be at least a small handful of people that write a modding interface for others.

strictfp 6y ago

Bedrock is by far the most popular version of Minecraft. It's the version used on all handhelds and consoles.

Rhedox 6y ago

Minecraft is also a prime example for why Java is bad for game development. The GC is constantly overworked because Java has to allocate immutable vector and matrix classes on the heap. In other languages (like C# for example) you'd make that a struct and enjoy value type semantics and stack allocation (in most cases).