A company as large as Microsoft has resources to do a lot of things, but you’re not borrowing resources from the Office team to help on this project.
The relevant measurement is the resources Mojang has as a studio. And I expect the decision here is that they don’t want to commit to the long term maintenance of three renderer implementations on the Java side.
Another concern is that modding is a major part of why Java Edition is so popular, and that includes shaders specifically. This is already going to cause chaos in the modding world as it is, no need to compound that by making shader mods that much more burdensome to maintain.
Java garbage collection gets out of control when cramming 100+ poorly optimized mods together. The bedrock edition is great in theory but the proper mod API never appeared. Regardless, people have accomplished some really impressive stuff with commands, but it is an exercise in pain.
The other issue with bedrock is it is far from feature parity with java. If these two things were hit then java could be reasonably retired. However we are decades too late in it being acceptable to introduce a breaking change to mod loading. So it's java forever.
>Consider this, if the mod interface was C/C++, do you think those poorly optimized mods could be trusted to also not leak memory?
Of course. Because they would fail loudly and would have to be fixed in order to run. Garbage collection is a crutch which lets broken things appear not broken.
Memory leaks very often don't fail loudly. Especially if they are slower leaks which don't immediately break the application.
A lot of the memory problems that you can see without a GC are hard to find and diagnose. Use after free, for example, is very often safe. It only crashes or causes problems sometimes. Same for double free. And they are hard to diagnose because the problems they do create are often observed at a distance. Use after free will silently corrupt some bit of memory somewhere else, what trips up on it might be completely unrelated.
> A lot of the memory problems that you can see without a GC are hard to find and diagnose
The nastiest leak I've ever seen in a C++ production system happened inside the allocator. We had a really hostile allocation pattern that forced the book-keeping structures inside the allocator to grow over time.
To be fair, I've seen something similar with the JVM, though it recovers. G1GC when it was first introduced would create these massive bookkeeping structures in order to run collections. We are talking about off JVM heap memory allocations up to 20% of the JVM heap allocation.
It's since gotten a lot better with JVM updates, so much so that it's not a problem in Java 21 and 25.
> Consider this, if the mod interface was C/C++, do you think those poorly optimized mods could be trusted to also not leak memory?
Garbage collection does not solve memory leak problems. For example
- keeping a reference too long,
- much more subtle: having a reference to some object inside some closure
will also cause memory leaks in a garbage-collected language.
The proper solution is to consider what you name "poorly optimized mods" to be highly experimental (only those who are of very high quality can be treated differently).
> Garbage collection does not solve memory leak problems
It solves a class of memory leak problems which are much harder to address without the GC. Memory lifetimes.
It's true that you can still create an object that legitimately lives for the duration of the application, nothing solves that.
But what you can't do is allocate something on the heap and forget to free it. Or double free it. Or free it before the actual lifetime has finished.
Those are much trickier problems to solve which experienced C/C++ programmers trip over all the time. It's hard enough to have been the genesis of languages like Java and Rust.
There is no "must use GC" mode, as far as I'm aware, but the footguns you describe only exist if the programmers opt-out of the GC. It's somewhat similar to using JNI/FFM in Java: it's possible to escape the safety of the VM. Though it's much easier to do so in D.
I always had trouble running bedrock as a household server. Specifically it would stop accepting connections and required daily restarts. Java was much more reliable.
Skins, media packs, servers, hosted realms, upsales through all consoles, multiple copies for multiplayer with/between your kids… also a mass revolving shit tumbler of account stuff on the backend that invalidated lots of old accounts…
I bought during the beta for a lifetime of goodies, had to buy it again after the buyout, then again after an update to MS accounts wasn’t acted on, and then for the Switch. I’ve bought Minecraft 4 times, with another on the horizon if it keeps popular.
That was probably their intention, but Bedrock has proven to be full of papercut sized bugs, and maintaining 1:1 behaviour with Java has also proven really difficult. Redstone is notably different/broken with the exception of trivial circuits.
Until it's possible to convert your world to Bedrock and not have anything in your 'finished' world break, except maybe some giant Redstone machine or one or two known annoyanced, I doubt they'd do it. Mojang presumably still has some autonomy within Microsoft so long as the money keeps coming in, and Mojang presumably knows that pushing this too early is a bad idea. But Microsoft being Microslop, who knows, maybe they'll just do it anyway.
I don't think 1:1 behaviour with Java was ever the intent. Redstone works differently due to a combination of different design choices, like not breaking in water (although I can imagine that being an accessibility thing for console players) and less technical debt, making things like movable tile entities possible.
I don't know what you mean by media packs, but the server software is free, and I believe all of the skins and maps released by Mojang itself on Bedrock's marketplace are also free. It's the third-party stuff that costs money, although I assume Mojang takes their cut.
They do have a bunch of add-ons now with Realms notably, but I wonder if this revenue goes to Mojang or to another Microsoft branch for tax reasons. To say nothing of derived media, plushies, Legos etc.
The relevant measurement is the resources Mojang has as a studio. And I expect the decision here is that they don’t want to commit to the long term maintenance of three renderer implementations on the Java side.
Another concern is that modding is a major part of why Java Edition is so popular, and that includes shaders specifically. This is already going to cause chaos in the modding world as it is, no need to compound that by making shader mods that much more burdensome to maintain.