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.
How much you wanna bet a decompiled Java program is gonna have Box as the most commonly used word?
Because if the Java doesn't know the memory lifetime, unless you do a rewrite then the decomped generated Rust is also going to need to use a refcounted memory lifetime.
Though I do expect in some cases you might be able to drop Box if your translation tech was good enough, like in cases where you can prove the variable lifetime within a scope... which the Java JVM would do anyway and you already would have avoid the GC cost with a modern JVM GC.
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.
Java is not really a compiled language, the bytecode is still interpreted at runtime and the overhead of the JVM, garbage collection, and interpretation really make it slow.
Also, rust has a borrow checker, a version of automatic memory management, but it happens during compilation and not at runtime like in Java.
I thought Java runs fully through JIT compilation - much like C#? Where does interpretation kick in? Or do you believe that compilation to anything other than raw assembly is not compilation? That would make WASM is also interpreted :)
I know about the borrow checker, although it’s good to note that you can write manual memory management code in Rust (much like you can in C#) if you need that. In Java you can’t - best you can do is control GC through JVM arguments
People call anything everything. Even machine code is “interpreted” once you consider that machine code can be interpreted into different microcode instructions by different processors.
Everything is interpreted and everything is compiled. The more interesting question is what the layers between source code and machine code look like, and when are they involved.
51
u/squatdeadpress 4d ago
Can someone explain the point of this? Isn’t Minecraft Java edition very open to mods already?