upvote
It really wasn't and was always dubious.

A lot of the advice, for example, suggested using CMS. Which has been a terrible garbage collector almost since it was added to the JVM. When G1GC landed in 8, that was the correct GC to select for minecraft. Even the parallel collector would have been a better option than CMS in a lot of cases (sub 4gb heaps).

It was placebo. People wanted there to be SOMETHING that made things better so they reached for the billion different flags on the JVM (rather than fixing the underlying code). I've seen the same sort of mentality professionally and it's basically always been wrong.

reply
> rather than fixing the underlying code

There's not much you can do to fix the underlying code if the language doesn't allow you to declare a struct Vector3 { float x, y, z; } without heap-allocating it.

reply
Yep, once people discover the multitude of JVM flags the cargo culting begins...

It really applies to anything with a huge number of options, I remember similar things from back when I used Gentoo and the wild suggestions I'd get for what exact CC/C++ compiler options to use...

reply
It was more like Minecraft code was horrible, than anything else.

Creating objects like crazy, range for in hot paths, not caring about data representation, chosen algorithms,....

JIT and GC were already doing heroic efforts.

Yet, it settled Notch for life, which is something to take into account in the usual question regarding which technical stack for games.

reply
For sure. The tech only needs to be good enough to support the game design. For some games that means very high optimisation is needed, and for others it's enough that the screen can refresh before the user gets tired of waiting.
reply
Minecraft 1.7.10, covered in mods, can run fantastic (300+ FPS) if Java 25 is used. That used to be impossible.
reply
Thanks to the Gregtech New Horizon folks.
reply
Yeah at the time it was bad. Now, it's a pretty nice codebase
reply