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.
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.
for the parts that don't need high performance. And for leveraging existing libraries, if any are suitable.
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.
Also significant game state is not only represented by renderable content.
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).
Really? 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.
Especially now with ZGC, not even tiny freezes should happen.
Expand?
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...
The links I picked are a bit random but they'll get you going with the basics.