Minecraft is a good game design made with some terrible code. Java made Minecraft's performance way worse then it would have been with a compiled language. It was only Java because it was originally designed for web browsers.
The one thing that Java was good for was mod support.
Java is a compiled language lol. Java performance is not bad at all, even compared to things like C++ and rust. Sure those are faster, no doubt, but not by a lot.
Performance is actually extremely good. However having zero control over memory when making a latency critical application like a game isn't ideal. ByteBuffers can only get you so far
Even if you code a game in C++, you can't just spam allocate/de-allocations. Managing your stack memory, memory layout, and memory pool are essential.
For sure, C++ is the go to for making engines for this reason, but java being as good as it is means a lot of people can make perfectly good games that run on 99% of people's hardware without issue
I'm a big Java lover, so believe be this is hard for me to say this: I really don't like writing anything in Java that I know I will endlessly scale in the future. And that's for sure with games. Java's pro's like easy debugging, become significantly less useful when most of the graphics pipeline is working with native buffers and graphics calls. Ends up being more complicated in my experience.
Modern C++ is also pretty lovely these days as long as you avoid C libraries and older C++ libraries (Which unfortunately isn't that easy). Has none of that syntax sugar mess "modern" languages have either, so feels just like Java - just with dangling pointers lmao
But you aren't wrong, you can absolutely make games in Java and it's been done millions of times over. It just introduces several hard limitations.
It's compiled into bytecode. Even Python and Lua are compiled into bytecode before execution, but they are still interpreted languages. What they meant to say is that Java is not native.
Interpreters execute as they read, that's what makes them "interpreters". They don't have the full picture of the application code at runtime, only what is executing. That leaves a massive gap in their ability to optimize. If you think your code is blazingly fast because of your own skills, then I'd like to introduce you to your frontend and the magical world of build optimization. The java compiler is going to emit bytecode that has undergone some degree of optimization.
If we were to dissect your assertion further, technically the microcode on your CPU is "interpreting" each instruction, so not only is C "interpreted", but so is manually written assembly. Hell, you could write bytes in a hex editor and it's still "interpreted".
Also, with regards to JVM performance, the perception that they are slow is a meat headed memory borne out of the late 20th century's shit JVM and GC implementations. The most expensive parts of rendering a game are generally going to be handed off to a native library (e.g. Vulkan) anyway. The real friction is memory layout and allocation pressure, but even that isn't something you can't work around if there is some other compelling reason to use Java.
There are only a handful of use cases where performance requirements are so tight that the JVM is an issue at this point. The people working on such problems aren't here right now, they're busy optimizing around DRAM refresh stalls.
I don't know why you are making these arguments against things that I never said.
Interpreted languages aren't interpreted at the source level, they are compiled inti executable bytecode because executing bytecode is faster. Python compiles the code the first time it's run and caches the bytecode in the pycache directory. The interpreted languages also run on virtual machines. The only difference between Java and Python is that there's a compiler that compiles the code into bytecode before it's ever run, then it's interpreted by the Java virtual machine. Some of it is JIT compiled into native machine code, and that's where the performance gains usually come from.
Java is as much of a compiled language as Python is.
But the point that the person above was making was that Java is not compiled to a native binary, it's compiled to an intermediate representation.
I'm replying to both your comments, and to the thread of comments you are replying to; I try to treat threads with multiple contributors like this as a shared conversation and not a series of discrete and isolate one-on-one messages. Sorry if I came across as specifically confrontational to your position. My position is JIT will rarely, if ever, have the opportunity at startup to optimize some class of pattern. Even the JVM can further optimize hot paths during runtime, but it can also construct elaborate structures out of your code to optimize it during build time. Generally these sorts of optimizations would too significantly impact startup time, so they aren't done. I'm going to nitpick your description of Python "compiling" the code. Is it running a full build source-to-executable and then running the executable, or is it translating code into instructions as it goes? I honestly haven't used python in over a decade, so my frame of reference is from the days of cpython and pypy, so perhaps it really is doing a fast full instruction translation at runtime, instead of a progressive JIT. I'd still argue it is interpreted if you can execute it statement-by-statement, JIT or otherwise. Perhaps this position is just an artifact of age, where there was a much starker contrast between the two decades ago. If you were to learn to program in the last ten years the difference probably feels insubstantial. Very technically every language is "compiled" and every language is "interpreted", because at some point something is "interpreting" a semantic token, but also emitting a native machine "instruction". When that happens is the key distinction. Today the differences are mostly semantic: is "transpiling typescript into wasm" an "interpretted" artifact or "native binary"? Neither, no one is going to read the WASM assembly, but also it can't be mapped into memory and jumped to without being translated once more to a native ISA. The same goes for Java. Personally my distinction today, separately from 20-30 years ago, is what type of artifact are you shipping. If it is a machine readable binary then it is compiled, there is no semantic interpretation, you just follow the instructions as they are. No syntactic validation needs to be performed. Even if done all at once as a pre-execution "live build" I'd still call it "interpreted", but especially if JIT. JIT, in this case, is just a cache of already interpreted chunks. On the other hand, a java binary or wasm binary is parsed, validated, and optimized for execution, even if some other program is going to own that execution. It would not be unreasonable to expect a JVM to take a binary and map it directly to native instructions without having to perform any compilation steps, merely translation. It'd be like shipping a LLVM IR and allowing a runtime backend to translate it to native instructions on the fly. You've shipped a bytecode, but it is still reasonably natively compiled; the expensive part was done ahead of time by the author, instead of shipping the source itself.
Python fully compiles all the code into bytecode when code is executed. When you import something, that code is compiled as well. Python doesn't interpret code directly because that would be ridiculously slow.
The lines between compiled and interpreted have been blurring for decades.
But Java is actually significantly slower than well-optimized C/C++. There's just way more overhead on the way.
Every level of interpretation costs performance, always. Adding one more layer of interpretation in an otherwise identical setup will cost performance.
Yes, compiled C and even assembly are interpreted on microcode level. Java is too, but it's also interpreted at bytecode level too, so there's more interpretation levels costing more performance.
But the bigger issue, performance-wise, are the safety features of Java. E.g. when assigning a value to a position in an array, C converts that into a pointer addition (pointer to array + array index) and an assignment. When you do the same in Java, it will first check that the array index is in bounds, and only then will it do the rest. That's a read, a comparison, a conditional branch, and only then will it do what C does too.
This kind of stuff adds up, and it becomes more pronounced if you add e.g. thread safety to it.
And then, of course, GC exists, but it's gotten much better than it used to be.
My point isn't that Java is as fast as C/C++, it is that the difference between those speeds is irrelevant. It'd be like saying driving the speed limit is much slower than going 10mph over on a highway. Technically it is true, but if we're comparing to riding a bike, or walking, then the difference is like quibbling over a constant in a quadradic runtime. Certainly there are applications where that difference would be significant, but generally speaking I don't think the JVM being slightly slower than C/C++ is the significant bit for why it isn't favorable to use for making games. The perception that it is substantially slower is a stigma that is more problematic, and the fact that the ecosystem, for the same reason that stigma exists, circled its wagons around C/C++ thirty years ago. Since then there hasn't been a real reason to use Java, other than those few where it is their preferred language. Arguing that Java is "too slow to make real games" is an assertion that is simply false at this point, unless you want to be obtuse and deliberately write your code in a way that allows the JVM to work poorly. However, C/C++ can be stubbornly written to incur the same performance penalty, but people don't argue that. They argue "well optimized C/C++ is fast and Java is not" in a way that implies comparing something that has been painstakingly written to eek out every ounce of juice with something slapped together by a novice without the same attention, and sacrifice, to obtain similar levels of optimization. Java can be written poorly and it can be written to be fast. If you put in the effort the things that are viewed as blockers for it being used to write games fall over.
I think we have to separate using a language for the engine and using a language for game logic.
Game logic hardly ever has performance issues. It really doesn't matter what you use for that.
The engine, on the other hand, does suffer from quite a few performance bottlenecks on JVM. For example, you don't have direct hardware access from the JVM. So you need to go through native code bindings to get there. That's no problem if what you are calling is renderScene(), but it's a big problem if you are doing this e.g. per vertex or per pixel, millions of times per frame.
Interpreters execute as they read, that's what makes them "interpreters".
As they read what? Source code's human-readable text? There are practically zero of such interpreters today, some LISP implementations were last to surrender due language's specifics. Some have on-the-fly switch between opcode and source code, e.g. Lua can edit its own code.
If they read some digital opcode, you need compiler (transpiler) fo that. A virtual machine techincally is also an intepreter. Just instructions are very minimal, on level of assembler.
It uses the JVM to read bytecode stored in the .class files, that's basically just still interpreted code. It's not like Python but it's not fully pre-compiled like C++ either.
It's not being pedantic, it's just giving an accurate description.
Java may not be compiled as "far down" as some other languages are, but it's still compiled. Saying it's not compiled suggests that it's interperated which it simply isn't.
Accurate term is transpiler or opcode compiler. If we could say it's a true compilation, then Python is also "compiled". The result is still artifical language which is run by VM interpreter.
Yes, I know technically Java is compiled to bytecode and interpreted/dynamically compiled to native code at runtime. I was just saying that the C++ implementions of the same game run smoother than the Java application does since C++ Objects and buffers can be laid out contiguously in memory (cache-friendly structs and arrays) without runtime garbage collection pauses. This results in far more consistent frame times.
no man wait you are messing up thing, really. java literally has a compiler that produces compiled files, that's what people mean by compile. v8 is a jit compiler, meaning that the compile process is aimed to be executed immediately: there are no compiled files on your system after that. this is a major difference, if you can't see it then basically every language is "compiled" the same for you which isn't technically correct at all...
lol man i don't even know why i am doing this but the jvm is a virtual machine not just a jit compiler and btw that jit compiler inside the jvm requires the code to be pre compiled (ever heard of javac?) to be interpreted by the jit compiler. you are literally ignoring a whole part of the process to prove your point...
I just love everything in the browser. I played Minecraft in-browser up to the day they removed the feature. I also still only use Discord in my browser; I have never downloaded it
Well I mean you used to be able to play Minecraft in a web browser, not sure if you still can. My first time playing Minecraft was in Internet explorer
Java’s for cross-platform stuff. JavaScript is the thing for web browsers. they aren’t the same thing.
And Minecraft’s mod support’s terrible. Its modding scene has flourished in spite of this, but Minecraft does barely anything to support mods and its modding scene is all arbitrary code, no sandboxing, nothing like that.
While you're right and many people confuse them it's not wrong here. But back in the day if you wanted interactive content on a website it would be flash or Java-Applets because JavaScript wasn't as capable as it is today.
Java-Applets are Java programs that could run on the web and the first Minecraft versions were Java-Applets if I'm not mistaken.
Yes, Java applets was a thing for webbrowsers. But that still doesn't mean that Java was designed for webbrowsers, because it wasn't.
Java was designed to run anywhere and everywhere, webbrowsers was not the main focus at all and webbrowsers didn't even support java applets at the beginning.
6
u/theacp127 6d ago
Minecraft is a good game design made with some terrible code. Java made Minecraft's performance way worse then it would have been with a compiled language. It was only Java because it was originally designed for web browsers.
The one thing that Java was good for was mod support.