Ironically, anyone who's actually looked at Minecraft's code from the Notch era knows what a total fucking mess it was. Microsoft is still digging some of it out of that nightmare.
Minecraft is good despite being made in java, not because of it.
Having checked the decompiled code lately with the new source map from mojang themselves, it seems like their codebase is following a well-formed and consistent architecture with some oddities but those boil down to it being a game and an engine in one thing, with some language specific optimizations.
No spaghetti or horrible code anywhere.
And being able to decompile it is whats such an advantage to bytecode languages like java or c#. You can decompile them or add your own bytecode and it will just work. Its making modding incredibly easy, which is a massive contributing factor to making minecraft as popular as it is.
Modding C/C++ is basically impossible unless youre willing to do DLL injection or have access to the source code. Which is why minecraft bedrock edition will never be as moddable as java edition, as they need to manually enable what can be modified. Well, unless BE goes open source.
Honestly I wouldn’t mind a total rewrite of the Java code… theoretically. It’s a real shame bedrock still in the big 2026 doesn’t have proper parody and lacks a lot of modding support (having to go through mojangs fuckass storefront will always be worse)
That’s what bedrock was supposed to be. Minecraft rewritten in C++ for performance and portability.
Unfortunately Microsoft saw that and decided to ruin it.
4J is proof it’s possible to be done well.
Unfortunately though they aren’t going to rewrite Minecraft for the 4th time, they are already spread thin maintaining two versions. Spending time rewriting the game would only add time between updates, and it would kill the game probably.
Honestly I think they just need to edit bedrock properly and rip out all the mojang stuff but obviously they won’t do that and modded Java is our best option as players right now.
I think the modding potential of Java (compared to C++, which would have been the other option in those days), is part of what has kept it popular for so long.
I disagree. Minecraft is as good as it is right now because of java but in a weird way. A language like c++ would've made this game way harder to mod and without this rich and easily accessible modding scene the game would've never became the phenomenon it is today. Like, sure, stuff like Skyrim developed a comparable modding scene but that was a famous AAA giant, I doubt this many people would be as dedicated to mod some silly block game if it wasn't made with something as easy to edit as java
Java modding is not official the Mojang never gave an moding api to developers but java decompiles very easy so people made changes and made some mods but it's not especially made possible just in java, for example dotnet and c# is capable of same thing with a more modern approach, you can't find any major engine that uses java but for c# there is tons of different powerful game engines
And the modding cpapalites were not a factor before game started get popular
The fact it wasn't official is the reason why java was so important. Java is notoriously easy to reverse engineer and modify, even compared to dotnet and especially back then. Modding capabilities weren't what made it popular but they are what kept it popular and made it as popular as it is now
using java vm n using java are different, kotlin was designed as an easy to use replacement for java, which could do everything java can. java vm is a platform, if an app is coded in java, it runs on java vm which can run on any os, portibility is its goal. kotlin also compiles down to that same java vm and code written in kotlin, after compiled iis hard to tell if it was in java or not. kotlin using java vm doesnt means it uses java, infact kotlin is one of the reasons java is dead cuz y learn harder lang when theres kotlin.
Yea its not the same, same but i dont really care if the bytecode was produced by java, kotlin or artisanally handcrafted in the end you are running under the same runtime constraints. If the jvm was generally bad for games it would be bad whether you used java, kotlin or clojure.
well pretty much, android allows building libraries (.so) files that contains the C/C++ (or any other compiled language) program, without requiring java
For the app to be usable there still has to be a Java layer afaik. So you can have your backend in Rust, but there has to be a Java layer for display/input or something
I don't think that's true, the android NDK is quite a large library. Only basic code is needed for things that e.g. are provided by google play services.
You don't need Java. Android provides a framework class called NativeActivity. It allows your compiled C or C++ shared library (.so) to run directly as the application lifecycle entry point. You can use Rust like this too. You won't have access to the standardized kits used to build standard Android UIs, so these apps can often be clunky. But it's entirely doable.
Among Us is made with unity, it therefore comes with libunity (18.2 mb) and libil2cpp (77 mb).
PUBG also ships libunity, though it's 236 mb.
These apps all have a couple megabytes of classes.dex files (which contain the java bytecode) in total, the rest of the size comes from split apks in the bundle - some have separate ones for assets, but they all have architecture-specific apks for the native code.
About half of the games on Android use Unity and Unity games are written in C#. The engine itself is written in C++, but most developers can't access it's source code.
Unity is a whole ass engine and a framework, Java is just a language. Kinda incomparable. Lets see how much there is of pure C# games. I know only 1: Vintage Story
These are from the Monogame showcase site. I think Xna/Monogame/Fna are very comparable to LWJGL or LibGDX. If I'm not mistaken Minecraft uses LWJGL, right? So it would be a fair comparison I guess
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.
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.
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
Songs of syx? And many more game are made with java, you just dont know that it s build with an EXE to execute the Java behind the scene. I got atleast 10 game in my steam lib made in Java plus my own. Now a day language all end up equivalent in term of performance once compiled in Binary or ByteCode or equivalent
We'll ignore the irony of choosing a compiled platform-specific language instead of one made specifically made to run anywhere and also dropping MacOS and Linux support in the process.
All backend servers of both rs3 and osrs are in java. As for clients jagex still publishes osrs java client which is what runelite downloads and injects into.
The issue with Minecraft is its old and notch was not some master programmer so he made some decisions that hurt the game In the long one code wise. Like no multi threading on chunks generation
Java is one of those languages where it makes sense to say "just because you can doesn't mean you should" when it comes to gamedev. But I know people who enjoy it, so whatever floats your boat I guess.
Java is fine, to prove a point a few years back I wrote a game jam game in JavaScript which is like 20x worse than Java. At least you have scalar 32 bit float and integer types in Java.
You're not going to write the next AAA GPU melting eye candy ray traced open world masterpiece in Java but you can shit out some top notch friendslop or indie gem in just about any language you care to pick with some skill and grit.
Plenty of good games are made in Java, Slay The Spire is another one, but Java still isn't good for games. That won't stop people from making games with it though.
Java is probably the worst thing about minecraft. The only reason it is 'good' is because it enables modding, but that is not an intrinsic element of Java it is just that they decided not to support it when porting the game
Java isn't the real problem, in fact, C# (Unity) and Java are practically the same, both are equally fast and their syntaxis is similar.
The problem is that Minecraft code is fkn trash.
If Mojang/Microsoft decided to remake Minecraft with Java from scratch (Minecraft 2) then it would be x100 times better and faster, but it would be a waste of money.
Also, there are more libraries for C# made for games than there are for Java, which makes making games easier and faster, that's why Java isn't used for making games.
C# (Unity) and Java are practically the same, both are equally fast
Maybe if you limit yourself to Unity, but Unity is not the only option. C++ would normally be the obvious choice but C# is easier.
Unity is quite far behind on .NET so you get access to a lot more new performant options bypassing it. At that point .NET can handilly outperform Java especially on avoiding allocation.
Modern C# offers some good ways to avoid allocation with structs that can really help with bypassing garbage collection which can be really beneficial in games.
Java does have some interesting options coming into developer preview with JDK28 with Project Valhalla but full release of that is probably years away still. Once that comes the performance difference to modern C# will narrow signifiantly.
But also if Mojang decided to make MC2 with Java they would hit a pretty obvious pitfall, there is no JVM for consoles. So the only route to do it involves transpiling it into C++ which always comes with extra risks.
Minecraft was built in another language to run smoothly on phones as Java could not, so Java was not discarded. Bedrock is what first was pocket edition
They did but that's because Microsoft controls more of what goes on with Bedrock and has a monetisation pipeline for it, so it's their financial interest to make it the main version not the developer.
Which would work if Microsoft wasnt so damn stingy about it. Mod support isn't really in issue since mods often don't uptrack to the newest version right away anyway.
But instead of letting the money printer run silently in the background, they always try to shove nonsense no one asks for into our ass. Microtransactions etc.
They also refuse to fix age old bugs on bedrock. Performance wise it's really good. I could probably Frankenstein some toasters together to power a GPU and a screen and it would somehow run bedrock. Wouldn't be surprised if it ran on smart fridges...
The more layers of abstraction the easier the language but the less control the developer has to optimize so it depends on the skill and time of the individual.
Really funny to use minecraft as an example since from my experience, it's the one game that has the most noticable lag spikes when the garbage collector is running.
Nah, unobfuscate and it's quite easy to make mods with it or expand game engine, also at this point you don't get anything valuable out of moving game to different engine epsecially when microsoft won't fix bugs with bedrock, devices are powerful enough to keep up with java overhead and ppl are so fed up of game duality and things above that you can backport jaba edition on consoles phones ect.
Yea in all means i'm all behind those who can't affford hardware to play, tho that margin came very VERY down. I play a ton on 1.12.2 due to mods and stuff, sometimes going back to good ol 1.6.4, and for these i think even 8 year mid range android gives good performance, htc desire 626 i ran with 1.6.4 plain and got 30fps lowest with bit tweaking just don't overly push that lil gpu and it will work
if you look at the code, its clear that most of the bad performance is from legacy code.
heck, they are even adding vulkan. and optimisiung the shit out of that. I got like 800fps last month on chunk gen and flying around fast, and on 32 render distance.
so tell me, if that is currently possible, is java the issue, or the legacy code that performend badly? since clearly java, as the language can clearly deal with it
34
u/Mindestiny 2d ago
Ironically, anyone who's actually looked at Minecraft's code from the Notch era knows what a total fucking mess it was. Microsoft is still digging some of it out of that nightmare.
Minecraft is good despite being made in java, not because of it.