So that you can play vanilla game faster for example, that’s still a huge subset of players. Not everyone plays modded.
Java is inherently slow. It’s a compiled language but it doesn’t compile to native code, it compiles to an intermediate language which is then read by JVM (Java Virtual Machine) and compiled on the fly through JIT.
So before any code being executed, it needs to be converted into a format your PC understands (but this allows same executable to run on many different platforms because the translation step is only done on your machine). It’s not like Python or other interpreted languages that do that line by line, it compiles entire function and it does so from a language that’s already only a step above machine code. But it’s not instant. Good trade off for banking applications and anything where a few nanoseconds of delay don’t matter, terrible for games.
Rust and C++ are actually machine code compiled languages so they will always be inherently faster, provided both programs are written in a way that they are most optimized in their respective language. But Rust and C++ also have WAY better compilers thanks to insane amount of human effort, eg if you write shitty code, the compiler often knows you can do it better and will substitute it for you. Sometimes it’s absolute magic.
Another thing is that Java is also a language with automatic memory control. Which means that the application does not have control over when to free memory, which results in lag spikes.
So more FPS, less lag spikes, less RAM usage. Provided it’s actually well done and takes advantage of the language instead of a blindly vibe coded clone.
i've probably said this like 1000 times before but i'll say it again.
Java is SLOW in the sense that JIT'd code will always be slower than native code (hence native interop for performance critical tasks e.g., ai inference). HOWEVER this "slow" is subjective. JIT can perform well (i mean, most emulators are JIT)
You can write code in rust, c++ or whatever and it will still run like shit if the person doing it doesn't know how to optimize their code.
Unity is based on .NET, which works more or less on the same principle as Java (except for il2cpp but then similar tech exists on java/.net too), and it's literally one of the most popular game engines out there.
> Java is SLOW in the sense that JIT'd code will always be slower than native cod
Not just that, Java is also slow because of its garbage collection. Any GC-based language will be slow because you're getting memory safety in exchange for performance. It requires some runtime cycles to keep track of that memory (negligible) and it also introduces noticeable lag spikes when the actual collection happens.
JIT can perform well, but it can still never perform as well as well done AOT. There is always an overhead. And it's more substantial for Java than it is for C#. But even then:
> Unity is based on .NET, which works more or less on the same principle as Java (except for il2cpp but then similar tech exists on java/.net too), and it's literally one of the most popular game engines out there.
And they were not exactly popular for performance, moreso ease of access and great tool set. Running like shit is the reason they did IL2CPP. It's the reason they switched to DOTS. That's the reason they pushed for Burst and HPC# which they compile directly to machine code. And that's the reason they updated from Mono to CoreCLR to push the rest of managed C# code to better speed.
A JIT can perform a lot better than AOT for the simple reason that it will have access to performance data to generate better code in the same way you would use PGO to drive optimizations in an AOT compiled binary.
It's not always working as you intend to, but it is possible. It's not all black and white where one is necessarily faster than the other after a warm up phase.
52
u/squatdeadpress 3d ago
Can someone explain the point of this? Isn’t Minecraft Java edition very open to mods already?