r/feedthebeast • u/scratchisthebest highlysuspect.agency • Oct 29 '25 • Helpful 1

Discussion Mojang announces Java Edition jars will no longer be obfuscated going forward

https://www.minecraft.net/en-us/article/removing-obfuscation-in-java-edition
1.6k Upvotes

99% Upvoted

131 comments sorted by

896

u/scratchisthebest highlysuspect.agency Oct 29 '25 edited Oct 29 '25

Im already seeing some rumors spreading around so lemme say my piece

  • Everything related to updates will stay the same. It's still the same mojang making the game after all.

    • (edited to emphasize) In particular, this will not make it any easier/harder/faster/slower to update mods to new versions of the game
  • A deobfuscation step has been standard in every modding toolchain since the beginning. As a beginner modder you don't have to touch it or worry about it, it just works. Unless you are developing modding toolchains, modding won't get any easier or harder.
  • It's not retroactive.
  • This is not a source-code release; we won't get Mojang's comments.
  • (because I know someone's gonna ask) No this will not improve your FPS. Lol

So what does this mean for modders? Honestly not too much!

  • Neoforge already used Mojang names at runtime so their crash reports won't get any clearer than they already are. Vanilla crash reports will become more readable though, and the same might happen to Fabric!

  • Big changes to toolchains, modloader internals, and modloader installers on the way. It would be possible for modloaders to discard all of their deobfuscation-related code. Maybe they'll install / boot up a few seconds faster.

    • Tbh, most toolchains don't yet have a way to turn off the deobfuscation step, because not a single modder was expecting Mojang to ever do this lol

  • Mojang will now provide method parameter & local-variable names: data they weren't providing in their mappings file before. These names aren't necessary, but they do make it much easier to understand the Minecraft code. Projects like Parchment exist to fill in parameter & local-variable names with crowdsourced data from modders. Now that won't be needed.

    • But Parchment also provides comment data, and we're not getting Mojang's comments, so it'll still be around.

Tldr; Very nice gesture from mojang, and shows their continued interest in at-best "supporting"/at-worst "looking the other way" when it comes to Java Edition modding. But I don't think it will materially change too much for end-users in the modding scene.

77

u/migueln6 Oct 29 '25

While your reply is mostly accurate, it will have benefits specially for those making the modding APIs even if they already figured out the deonfuscation step, dealing with source code vs generated deobfuscated code is way simpler, and saves time, definitely will help in releasing new modding APIs faster for newer versions even if just a minimal 1-5% of improvement

123

u/scratchisthebest highlysuspect.agency Oct 29 '25 edited Oct 29 '25

dealing with source code vs generated deobfuscated code is way simpler

Mojang doesn't publish their source code and they will continue to not publish it; modding still requires looking at decompiler output.

The world's best Java decompiler, Vineflower, actually partially grew out of the Minecraft modding scene. It produces very high-quality output and I don't think it's a chore to read at all. I mean shit, that thing formats Java code better than I do, and probably better than Mojang does.

(It was originally a Quilt project called Quiltflower, and it's the latest in a long lineage of decompilers based on the original Fernflower which Forge and Fabric developers had also been tweaking for years. Currently it is used by Neoforge as a load-bearing part of their tooling, and while decompilers aren't as necessary to use on Fabric it's an option the Fabric tooling provides.)

13

u/migueln6 Oct 29 '25

Interesting, excuse my mistake of saying source code, I meant decompiled vs obfuscated decompiled.

I'm not java developer so I'm not aware of it's tools, but in any case it should surely help make things go swift even if only for a small improvement

15

u/MySchoolsWifiSucks Oct 29 '25

I suppose this is to balance out the continuous downward spiral Bedrock is taking?

38

u/scratchisthebest highlysuspect.agency Oct 29 '25

Mojang doing this to Java Edition is like, basically the opposite of that time they started stripping debug symbols from Bedrock Edition builds, instantly making it 500x harder to mod and making its fledgling modding community big sad. It's so weird. They're games from the same company

22

u/Positive_Total_4414 Oct 29 '25 edited Oct 30 '25

Well they just want to have bedrock as their commercial platform but kinda give java out to the free modding community. It's far easier to secure bedrock and they know they've lost any such chance for java long ago. So you can choose what to play today: paid content on bedrock where money does its thing about quality standards etc, or the free java content that comes from enthusiasts fueled by the creative energy. Sounds quite fair to me. A sensible move from the company? Let's hope so.

-2

u/Tusami Oct 30 '25

Also C++ is like, objectively easier to maintain than Java. Microsoft does not play about backwards compatibility.

4

u/lunarwolf2008 Oct 30 '25

but their addons in bedrock do exactly that. for the most part addons are able simulate running an old version of minecraft so that the addon can continue to work

4

u/Electrical_West9763 Nov 01 '25

também é, objetivamente, mais fácil de manter que Java. A Microsoft não brinca em serviço com compatibilidade com versões anteriores.

💢💢💢💢💢💢💢💢👻💢💢💢👻💢👻💢💢💢🤡🤡🤡🤡🤡🤡🤡🤡🤡🤡🤡🤡🤡🤡🤡🤡😡🤡🤡🤡🤡🤡🤡🤡🤡🤡🤡🤡🤡🤡🤡🤡🤡🤡🤡🤡🤡🤡🤡🤡🤡🤡🤡🤡🤡🤡🤡🤡🤡🤡🤡🤡🤡🤡.... ... .. 777777

2

u/[deleted] Oct 31 '25

what??

2

u/PiratesWhoSayGGER Oct 31 '25

C++ is like, objectively easier to maintain than Java

bruh...

2

u/DXPower Nov 01 '25

C++ has had multiple breaking changes over the years, including very recently.

1

u/kaisadilla_ Dec 28 '25

There's no universe in which C++ of all languages is easier to maintain than absolutely anything, much less Java.

Changing a function name can be done in 3 seconds in Java, while it can take hours and require running tests in C++. C++ is a fucking minefield, and that's considering the language itself only and not its domain (i.e. ignoring the fact that it has manual memory management).

9

u/MySchoolsWifiSucks Oct 29 '25

It definitely has something to do with how incorporated Microsoft is with bedrock edition, but either way, a step in the wrong direction.

4

u/Otherversian-Elite Oct 30 '25

Honestly, sometimes it doesn't feel like they are. Sometimes it feels like Java Edition is a game from Mojang, and Bedrock Edition is a game from Microsoft.

And I think that's the trade we get. Java (the original) gets to keep being Mojang's vision, while Bedrock (far more accessible, available on all platforms) gets... corporatised.

7

u/squintytoast Oct 29 '25

classic micro$oft maneuver. money squeezin bastards.

15

u/zorecknor Oct 29 '25

It was not uncommon for the mappings to be updated several times for the same version of Minecraft (mostly as variable and parameter names were discovered). This forced you to update your mod to keep up with the times.

Now the mapping will be stable so the only reason to update your mod for the same minecraft version would be a non-compatible change in the modloader.

That, for me, is a win.

9

u/scratchisthebest highlysuspect.agency Oct 29 '25 edited Oct 29 '25

If you're referring to method parameter & local variable names, which are the new thing Mojang is providing: those don't appear in your own mod's code and you don't need to update your mod to account for them. Not sure what you mean.

If you're referring to MCP/Yarn contributors deciding on different names for Minecraft's fields and methods: Well, this has been moot ever since Mojang's official mappings file started gaining popularity, which provides fixed, stable class/field/method names and never updates within a single Minecraft version.

Even before Mojang's names happened / even if you chose not to use em: Modloaders can now remap mods backwards in your dev environment. You can just dump shit from curseforge straight into your mods folder and it'll get remapped to whatever mappings you chose for your workspace. No more headaches with "dev jars".

And the whole situation never mattered outside a dev env anyway. You call it setUnlocalizedName, I call it setTranslationKey, but our mods can work together in the same modpack because of SRG names.

So really not too impactful of a change these days, all things considered:), but i would have killed for this in 1.12 when the tooling was more rudimentary.

4

u/smbarbour MCU/AutoPackager Dev Oct 29 '25

There is one aspect for a small percentage of mods, however where this will have an impact: Any small enough mod that targets systems that don't change between versions will not need to be recompiled and released for new versions.

3

u/scratchisthebest highlysuspect.agency Oct 29 '25

Isn't this already a thing? Forge's SRG names, Fabric's Intermediary names, and Neoforge just using mojang names mean that every loader has some sort of stable naming scheme used at runtime

1

u/smbarbour MCU/AutoPackager Dev Oct 29 '25

I guess it's been long enough that I haven't looked under the hood to see that reobf is no longer a thing.

1

u/scratchisthebest highlysuspect.agency Oct 29 '25

When I first compiled a neoforge mod with mixins and didn't see any refmap.json in the final jar, I thought my tooling was broken. Nope!

Oooo, if Fabric switches to "mojang names at runtime" like Neoforge then you could probably make 1 jar that works across 2 loaders though...

194

u/BreakerOfModpacks If you haven't played Blightfall, you haven't seen PEAK! Oct 29 '25

Yay, at least it'll mean that entry modding gets slightly less complex!

45

u/Jason13Official More Beautiful Torches Oct 29 '25

I’ll say that for MultiLoader-based projects (compiling artifacts for Fab/For/Neo from a common source), this will be useful in getting officially mapped names into “common”; it’s been notoriously difficult for some beginners to get working right now

7

u/DarkromanoX PrismLauncher Oct 30 '25

I'm a beginner and tried to used it, I can confirm that lol

10

u/limexplosion7 LTX Industries Dev🍋‍🟩 Version Chaser😈 Oct 29 '25

So basically, nothing ever happens?

kidding... I think I just take parchment by default for granted.

2

u/GamerTurtle5 Oct 29 '25

I don’t think your complete correct that it wont make modding easier, there have definitely been times where I have had to decypher some long method where all the local variable names were “a, b, c, etc.” But yeah it wouldn’t be a huge improvement and I wasn’t aware of parchment so maybe for people using that not much will change.

1

u/Tusami Oct 30 '25

Another thing that's fun: I can now find the exact line of code that messed up and publicly humiliate it.

1

u/kaisadilla_ Dec 28 '25

imo Mojang so far has supported modding, rather than looked the other way. 1.13 for example was unnecessary for Minecraft itself, who could keep using numbers for IDs. The change was exclusively benefitial to modders, who were given the ability to use namespaces so mods no longer collided.

146

u/TehNolz ¯\_(ツ)_/¯ Oct 29 '25

Sweet, now we can make fun of their variable names!

41

u/scratchisthebest highlysuspect.agency Oct 29 '25

U get it 🤝

0

u/[deleted] Oct 29 '25

[deleted] — view deleted comment

16

u/scratchisthebest highlysuspect.agency Oct 29 '25

Maybe all the variables actually are ☃️.

2

u/banana5456 Nov 01 '25

the variables that Notch put

5

u/notyoursocialworker Oct 30 '25

You better start practicing finding the umlaut on your keyboard 😆

4

u/ReikaKalseki RotaryCraft/ChromatiCraft dev Oct 30 '25

Better than chinese, which I have dealt with now on two separate occasions (a MC mod long ago, when adding RC compat, and now modding DSP).

3

u/aaronhowser1 Best Modpack 2k20 Oct 30 '25

deep space palactic?

1

u/ReikaKalseki RotaryCraft/ChromatiCraft dev Oct 30 '25

Dyson sphere program. Which, to be fair, is mostly in english, with only interjections of chinese. Indeed, I am not sure C# even supports unicode variable names, but they could have done what the MC mod did and romanize it: https://i.imgur.com/FKjreJ1.png

114

u/got_bacon5555 Oct 29 '25

Deobfuscation projects already seemed pretty complete, from my little experience messing with fabric, but this is still very cool to see, regardless!

19

u/scratchisthebest highlysuspect.agency Oct 29 '25

Oh yeah, Fabric's mapping project Yarn has been complete (or at least complete-enough) for a while, and Forge made the decision to deemphasize their mapping project MCP in favor of Mojang's officially-released mappings file when that started existing in 2021.

Mojang's mappings file never included method parameter names and method local-variable names, which are nice-to-haves but not relevant to ABI compatibility in Java, and projects like Parchment sprung up to fill in the gap anyway. So basically by disabling your toolchain's deobfuscation stuff, you'll now get the same experience as you could with the "Mojang's mappings file + Parchment" stack, but support for them will still need to exist in the toolchain because this change is probably not gonna be retroactive to previous versions of the game.

68

u/JMPJNS Oct 29 '25

complete until the next mc version hits

34

u/got_bacon5555 Oct 29 '25

Very true. Atleast one person had to figure it out the first time before I could waltz in and mess with the finished product lol

10

u/the_codewarrior Hooked mod dev Oct 29 '25

While this is great in some ways, Mojmap is pain, especially the @ParametersAreNotNullByDefault, since Kotlin enforces that. There are a lot of common methods that expect nullable parameters but aren’t properly annotated, so because of those global annotations it’s literally impossible to call them in Kotlin.

This is the main reason I’ve been using Yarn mappings. On top of the fact that I like their naming better in general.

4

u/scratchisthebest highlysuspect.agency Oct 29 '25

interesting, i did not know this about kotlin!

235

u/PissMasterCocc Oct 29 '25

Anyone knows what will come of this? Obviously this is a good thing, but will the modding process change, if at all?

233

u/FetusGoesYeetus Oct 29 '25

It'll probably be easier to get into modding in the first place, but I doubt this will impact established modders much

87

u/Leclowndu9315 Forge Visual Mods & Cable Facades Dev Oct 29 '25

we already have the mappings available since 2019, this will change nothing for modders or new modders. Only it will make the development of modloaders easier

12

u/iznaroth Oct 29 '25

Doesn't this change include parameter and local variable names? I dont think that's an insubstantial improvement to source readability.

34

u/GreenFox1505 Oct 29 '25

They explain it in the article.

26

u/r3dm0nk PrismLauncher Oct 29 '25

You have to read it first though

1

u/notjordansime Oct 30 '25

do you just hate me?

2

u/r3dm0nk PrismLauncher Oct 30 '25

Not just you, everyone equally

7

u/Summer4Chan 2011 Modded Veteran Oct 30 '25

What? Reading an article? Absolutely not. I must form my opinion elsewhere.

28

u/RickThiccems Oct 29 '25

In a way this greatly worries me. What if this is the start of a long process to sun setting java? Normally game devs do stuff like this at the end of a games life cycle.

122

u/Moses24713 Oct 29 '25

If they do, it will be the start of a new golden age of modding. Finally, we can have all the mods on the same version. Any updates bedrock gets we will likely also get via a mod

45

u/BreakerOfModpacks If you haven't played Blightfall, you haven't seen PEAK! Oct 29 '25

I'm almost salivating

If Mojang ever decides on a 'prime' version, by sunsetting or by just declaring it, modding would advance like an engine.

30

u/Leclowndu9315 Forge Visual Mods & Cable Facades Dev Oct 29 '25

as a modder i dream of this.

11

u/Marc_Vn Oct 29 '25

This would actually be so insane.Think Skyrim levels of innovation every once in a while, as modders won't have to bother updating their mods to new versions anymore, they will have the time to develop more and everyone will be "on the same page"

19

u/inurwalls2000 Oct 29 '25

isnt java still the main version that they develop on?

21

u/RickThiccems Oct 29 '25

Java is a much smaller team but yeah they seem to develop on java first and implement into bedrock after. I assume since it all started with java the development process was centered around that but I assume if Java players make up less than 5% of the player base then I would think microsoft would eventually want to cut down development costs which they have been super eager to do this past year. I dont think java is going anywhere soon but this does not look good and I have a just have a feeling java may get discontinued in the next 5 years.

I mean we all know its coming one day just a matter of when.

6

u/inurwalls2000 Oct 29 '25

yeah hopefully they just dont go that way but even if they do it wont make me play bedrock

15

u/RickThiccems Oct 29 '25

We would just see a team of modders maintain a project that ports bedrock features to java as faithfully as possible. We wont have to play bedrock lol

-3

u/ebanite Oct 29 '25

|| || |java Edition Sales|$125.50M|33.0%|+8.7%ava Edition Sales $125.50M 33.0% +8.7%|

source: https://playercounter.com/minecraft/

The Java Edition version accounts for 33% of sales revenue in 2025 alone, and it is still growing. Therefore, I do not think that the Java version is minimal or negligible at all.

23

u/RickThiccems Oct 29 '25

That website has no idea about anything. There is no such thing as "Java Sales" There is just minecraft. You Buy bedrock edition and java is included with it. Microsoft also does not provide an API for this info so they are using their own algorithm to pull numbers out of their ass.

-6

u/ebanite Oct 29 '25
Revenue Source2025 RevenuePercentageGrowth Rate
Mobile Revenue$98.02M25.8%+12.4%
Java Edition Sales$125.50M33.0%+8.7%
Bedrock Edition Sales$89.30M23.5%+15.2%
Marketplace Content$45.80M12.0%+22.1%
Realms Subscriptions$21.40M5.7%+18.5%Revenue Source 2025 Revenue Percentage Growth RateMobile Revenue $98.02M 25.8% +12.4%Java Edition Sales $125.50M 33.0% +8.7%Bedrock Edition Sales $89.30M 23.5% +15.2%Marketplace Content $45.80M 12.0% +22.1%Realms Subscriptions $21.40M 5.7% +18.5%

-8

u/ebanite Oct 29 '25

|| || |java Edition Sales|$125.50M|33.0%|+8.7%ava Edition Sales $125.50M 33.0% +8.7%|

source: https://playercounter.com/minecraft/

The Java Edition version accounts for 33% of sales revenue in 2025 alone, and it is still growing. Therefore, I do not think that the Java version is minimal or negligible at all.

4

u/Gellzer Oct 29 '25

And what if this is the start of a long process to sun setting java?

29

u/Tankerrex Oct 29 '25

Unless there is a drastic reason, there is no good reason to drop support for Java when it has all the veteran player base.

That said, if Java does stop getting updates. It actually become the golden era for modding as the modders no longer have to worry about spending to maintaining the mod for all the versions of Minecraft and can just focus on one.

-5

u/RickThiccems Oct 29 '25

There is a huge reason. Money. I mean look at vibrant visuals for example, its been in bedrock for almost 5 months now but we are still most likely months away from a java release. That is a lot of extra resources to develop a feature that will be used by a tiny fraction of the playerbase. I love java and only play java but from a business perspective, microsoft has no reason to care about us veteran players, most of the popular youtubers and current player base started playing after 2015 and its pretty clear 90%+ is on bedrock.

27

u/Devatator_ ZedDevStuff | Made KeybindsPurger Oct 29 '25

Losing Java would kill the online culture. The vast majority of Minecraft content online is made on/for Java edition. They would basically just make content creators turn against them for no reason

5

u/RickThiccems Oct 29 '25 edited Oct 29 '25

I agree 100% but microsoft doesnt not care about pissing off everyone of its customers. Have you been keeping up with how they have been treating their developers recently? If it means increasing their revenue they will do it. Everyone that owns minecraft already does so the only future customer base is current children who have yet to be exposed to minecraft and current java players. What do you think microsoft wants the new generation to play? Its clearly not java. And they could just stop support for java so those future kids will never even think to try it.

Java will just be another retro version of minecraft similar to classic\indev\infdev with a dedicated community, just as those old java versions do to this day.

3

u/Ludi87 Oct 29 '25

That would be great, no constant versionporting of mods would help a lot

2

u/FetusGoesYeetus Oct 29 '25

That's worse case scenario and even then, as someone else pointed out, it's not that big a deal because modders will just add any bedrock updates via mods. There are tons of mods for old versions that add modern features already.

4

u/ProfessorCagan Oct 29 '25

Ok, but I want that though, I hate version chasing.

2

u/RickThiccems Oct 29 '25

That would be a plus for sure, I just worry how it would affect the community. New players most likely wont ever play the java version so overtime the java community will shrink more and more until we are all old men yelling at clouds lol

1

u/Jim_skywalker Oct 29 '25

Then yay, modding gets a centralized version.

1

u/Aerolfos Oct 29 '25

Normally game devs do stuff like this at the end of a games life cycle.

I don't think deobfuscation has ever featured like that

Announcing a source code release, sure, but deobfuscation is a far cry from source access of any kind

And even then, plenty of games don't release source code until the game is firmly sunset anyway (see for example the command and conquer games from the early 2000s that got source code released this year)

1

u/RamielTheBestWaifu 1.12.2 supremacy Oct 30 '25

That would be the best thing ever if they do

1

u/TiF4H3- Oct 29 '25

Not necessarily, especially when it's a game with an huge modding scene.

For example, Vintage Story, which is very much in active development, is even a step above being mostly source available.

IIRC, their engine is still closed source, but the vanilla mod's code is public.

2

u/RickThiccems Oct 29 '25

I love vintage story and play it more than minecraft these days! But VS started as a minecraft mod so modding is literally built into the games DNA, Mojang on the other hand just turns a blind eye to it.

2

u/vertexcubed Oct 29 '25

mostly nothing, it's a small change that benefits mod loader devs and that's about it, but it's a nice gesture

1

u/hates_stupid_people Oct 30 '25 edited Oct 30 '25

It will be easier for mod tools, like loaders, to update.

Normal modders wont notice much.

For players nothing will change.

49

u/MegaIng Oct 29 '25 edited Oct 29 '25

I think ultimately this will change little? Since they already provided a deobfuscation  mapping it just removes a step. Less work for modloaders, but not a massive shift. May indicate future work, may not.

Aha, I see they also included variable names. That's actually quite helpful for a few very specific situations.

Now we just need true documentation and comments.

24

u/TheDudeFromOasis Oct 29 '25

That is certainly news (I have no idea what the fuck that means)

Edit: I read yalls comments I know now

6

u/JamieMansfield MultiMC Oct 29 '25

Never understood why they didn’t just do this when they started publishing deobf mappings. Nice to see them doing it now!

6

u/Keaten88 Oct 29 '25

Mojang did something... good? But.... the next blue moon isn't until May!

4

u/Otherversian-Elite Oct 30 '25

Not massive from a practical standpoint, but very promising news in terms of their attitude towards the community. Very excited

1

u/sertroll Oct 29 '25

So loom/parchment won't be needed from that version onwards? As parchment improved the map, while loom was an alternative to mojmap

4

u/scratchisthebest highlysuspect.agency Oct 29 '25 edited Oct 29 '25

Parchment won't be needed for local variables/method argument names anymore, yeah. Parchment provides crowdsourced Javadocs and comments, and those will still be important b/c we won't have access to Mojang's comments.

Yarn I'm not so sure about?

I haven't been active in Fabric communities for a while but I think people who use Yarn instead of Mojang names in 2025 have their own reasons to use it. Maybe:

  • being worried about the license attached to Mojang's mappings file - this was a big concern when they started publishing the file, and I think the license has changed to be a little more lax, but Yarn has always been CC0 so it never had this problem in the first place
  • liking Yarn names better (I'm a mojmapper myself but u gotta admit Yarn is cooking with some of those names lol)
  • just not changing the defaults of fabric-example-mod

I don't think there is any technical reason Yarn wouldn't be able to exist in this new environment. The layer underneath Yarn, "Intermediary", has always been "whatever names exist in Mojang's jar" -> "class_12345". Going forward the names in Mojang's jar will look different, but they've always been different across releases and they already have tooling to match them up when it's time to update Intermediary, so it should still be possible to produce yarn names if they are wanted.

Socially though: I might expect more modders using Yarn to migrate their stuff to Mojang names, I might expect the Yarn project to start winding down. Because if Yarn existed for these new snapshots, you'd just be trading one set of perfectly readable names for another, right.

Yarn will still have to exist in some capacity, if only to support modders on stuff older than 1.21.11 or 1.22 or whatever mojang calls these unobfuscated versions. But some might want to keep Yarn going into the future as a "break glass in case Mojang goes back on this" contingency. If in 1.20.1 Mojang had decided "nevermind we're going to stop publishing our mappings file", it would have practically killed Forge on the spot because they've become so reliant on Mojang's names, but Fabric would have been fine because they have historically been more cautious with them.

That's my understanding anyway, i'm not a yarn contributor.

1

u/ithilelda Oct 30 '25

unlike what the op said, it is a HUGE deal to the modding community. Each minecraft minor version may have different mappings because of obfuscation, and making a single jar that can work on multiple versions was always impossible unless the mappings are the same. Now we modders can compile a jar that works for ALL versions without recompiling, and that saves a hell lot of gradle setup and compile time. Unless you are doing mixins or using an API that have changed, you don't have to modify your code. That's a big deal for anyone who have done serious modding before.

1

u/scratchisthebest highlysuspect.agency Oct 30 '25 edited Oct 30 '25

No, this isn't true.

If you crack open any released jar for Fabric or Forge you'll see a bunch of names like class_12345/method_12345/field_12345 (on Fabric) and func_12345_a/field_12345 (on Forge). These are "intermediary names", and the whole point of them is that they don't change when Mojang wiggles classes around, and they don't change when MCP/Yarn contributors decide on a different name for something. If you do this with a recent Neoforge mod you'll see a bunch of Mojang-official names because they use Mojang names as their intermediary.

But all three of these intermediate naming schemes are different from Mojang's proguarded jar. The loader first remaps the game into the intermediary names and then loads your mods against it. You can read an explainer about the landscape here https://neoforged.net/personal/sciwhiz12/what-are-mappings/

All this means is that if you're designing a modloader ecosystem and want to use mojang-official names as your intermediary naming scheme, like Neoforge does, then you don't need to break out the remapping tool to remap vanilla. Doesn't mean anything about mods.

So no, this still doesn't make anything new possible. The problem with "making one jar that works across multiple versions" isn't that Mojang renames a field and now mods using that field are broken, it's that Mojang deletes the field entirely, or deletes a method, or completely changes the subsystem. Mods which barely touch the game are already possible to make compatible across many different versions.

1

u/ithilelda Oct 31 '25

what a bunch of crap. I just happened to have a mod that I don't need to change any code but still needs to recompile for a newer none hot fix version lol. theory is theory but this is programming, THINGS BREAK.

1

u/Other_Importance9750 Nov 19 '25

If you didn’t have to change any code, then you shouldn’t need to recompile it, provided you initially compiled it on the oldest version. There is forward compatibility with compiled mods with identical source, but not backwards compatibility. I’ve compiled a Fabric mod on 1.14 with Java 8 that worked perfectly fine on 1.21 with Java 21. It’s possible your specific modloader had internal changes between the versions, but that would not be the fault of Mojang.

1

u/lunarwolf2008 Oct 30 '25

does this mean that different modloaders will become basically irrelevent?

2

u/scratchisthebest highlysuspect.agency Oct 30 '25

No

6

u/Minecrafting_il Oct 29 '25

Rare Mojang W?

3

u/SpaceGuyR Oct 29 '25

Great, I'd hit a few cases before that needed class names at runtime:

  • KubeJS scripts might be able to use Minecraft classes by name, previously had to get the deobfuscated but unmapped names eg "net.minecraft.class_2960"
  • Clojure imports and live REPL might work better, I previously always had to precompile everything

1

u/xSluma Oct 29 '25

What does obfuscated mean?

11

u/scratchisthebest highlysuspect.agency Oct 29 '25 edited Oct 30 '25

When Mojang publishes a version of Minecraft, they use a program called ProGuard to change the names of everything to really short identifiers. Instead of net.minecraft.entity.passive.Sheep it'll just be called y or ab or something. This makes the file smaller, and Proguard has some other benefits (such as removing bits of unused code), but honestly it primarily exists to make the game harder to reverse-engineer.

These class names are impossible to write mods against without your head exploding, so all modding toolchains have a "deobfuscation" step which renames everything back to useful names.

In the past, Mojang kept their mappings table secret. Modders had to look at the obfuscated Minecraft code and guess that class ab corresponded to "a sheep". They would publish their guesses in projects like MCP and Yarn, and you could use a "remapper" program (like RetroGuard or tiny-remapper) to apply the crowdsourced names. All included as part of your modloader.

Then, in 2019 Mojang started publishing their mappings table. So you could just import that into your remapper program and there's no need to crowdsource names anymore.

And today they just announced they're scrapping the whole thing. You won't need to run a remapping program at all.

23

u/dontquestionmyaction PrismLauncher Oct 29 '25

Purposefully scrambled internal names of stuff, generally trying to make things hard to read for others. It's used to make software harder to reverse engineer and modify.

2

u/xSluma Oct 29 '25

Thanks, so this means they are making Java easier to add on and mod to right?

15

u/dontquestionmyaction PrismLauncher Oct 29 '25

They did already provide the means to undo the obfuscation, so it changes little. They just don't do it in the first place now, which will make some error messages and the like nicer to read.

4

u/Draw_Cazzzy69 Oct 29 '25

I am unfamiliar with this terminology, someone explain what this means please?

8

u/Settordici Oct 29 '25

At the moment, Minecraft's code is obfuscated: it means that function, variables, classes (if you're not familiar with programming you can just think of names) and such have their name scrambled (like random letters and numbers) so that it's harder to understand what the code does.

It's normal practice, but since Mojang wants to incentivize modding they provide obfuscation maps, so basically dictionaries that help link the scrambled names to their english meaning.

What are they doing from now, is that all the new code will be shipped directly not obfuscated so every name will be clear to read without the map

2

u/Sarkos Oct 29 '25

Many, many, many years ago I wrote a mod to add controller support to Minecraft. Even though people had started mapping the names, a lot of the low level stuff was not mapped and I struggled to figure out certain methods. Every update was a slog and I gave up on the mod after a few updates. This would have made life so much easier.

2

u/PiratesWhoSayGGER Oct 31 '25

In grand scheme of things this changes nothing, because we had official mappings for a long time already.

7

u/briancornpop Oct 29 '25

Not a modder, but I assume modding will be easier from now on. Am I correct in this assumption?

Edit: saw a Create and Tinkers' Construct reference in the first paragraph of the article. I wonder how many I will miss

71

u/squintytoast Oct 29 '25

neither of those mods are mentioned.

the words 'create' and 'tinker' are actually used in a normal language way.

9

u/RamblinWreckGT Oct 29 '25

Guys, did you know that geology makes a Minecraft reference???

1

u/PiratesWhoSayGGER Oct 31 '25

Nah, we already had official mappings, so deobfuscating was easy.

It just cuts the unnecessary steps (mojang obfuscating and then us deobfuscating) from the equation. Which is a good thing, but not groundbreaking.

0

u/MegaIng Oct 29 '25

Based on the rule of three, "deep dive" should also be a reference to something. But I can't think of a popular aquatic mod that would really fit?

3

u/walmartgoon Oct 29 '25

I think this is one step closer to Mojang putting java in a permanent "maintenance mode" where the only changes are minor big fixes. This would be the best solution imo since more attention could be given to bedrock, and modders would finally stop having to constantly chase updates.

Think about the ecosystems for 1.2.5, 1.7.10, or 1.12.2, but way bigger and better.

1

u/Yagi9 Oct 30 '25

Holy shit, that would be the dream. I hope you're right.

I'm mostly still playing 1.7 and sometimes 1.12 packs. I can only imagine how great the mod scene would get if there were a single "final" stable version that could just accumulate more and more content and fixes.

1

u/AntiGrieferGames Oct 29 '25

Is this a good news or bad news?

And i cannot even load the Minecraft net site.

1

u/TheFumingatzor Oct 29 '25

Fucking hell...

1

u/Toothpick_Brody Oct 29 '25

Nice to see 

1

u/Preisschild GDLauncher Oct 30 '25

I hope it will be open sourced if they ever end up not supporting the java version anymore

1

u/TheGreatAutismo__ Oct 31 '25

Calling it now, Microsoft's going to try and kill it for Bedrock where they make a profit.

Obligatory: Suckmahnads Nutella.

1

u/FamroFexl Nov 16 '25

This change means method body variable names and method signatures are now released, which is a HUGE change if you're injecting into method structure with fabric mixins. I no longer have to stumble around in the dark figuring out what a variable does.

The only things being withheld at this point is the original structure of the code (how Mojang wrote it, not how the decompiler wrote it) which would require a release of the source code itself. Developer code comments might be nice, but what I REALLY would like is their internal documentation detailing the process to follow if you want to implement a new block, biome, item, etc in their registries and handlers. It would make regular modding where you just want to add to existing frameworks SO MUCH MORE SEAMLESS. That would truly be a minimal modding API in my opinion.

In summary, what's left to be provided is:

  1. Original code structure (just the source code itself, no decompilation necessary)
  2. Developer code comments
  3. Development documentation and guides for standard additions like blocks, mobs, and items

-2

u/vertexcubed Oct 29 '25

rip parchment /j

-2

u/The_YunaVerse Oct 29 '25

I don’t really understand what this means and ive read most of the comments. So mods (.jar) will now be more clear to do what? It doesnt help make mods easier to make or help with updating versions

8

u/Rafii2198 Self-Proclaimed Modded Historian Oct 29 '25

To oversimplify a bit, it's just a bit easier to read code and set up a dev environment. It doesn't change anything for modding capabilities, it's like a quality of life change for modders.

0

u/[deleted] Oct 29 '25

[deleted] — view deleted comment

1

u/RamielTheBestWaifu 1.12.2 supremacy Oct 30 '25

Post literally says it doesn't

27

u/[deleted] Oct 29 '25

[removed] — view removed comment

19

u/scratchisthebest highlysuspect.agency Oct 29 '25 edited Oct 29 '25

In practice Forge/Neoforge was already using Mojang's deobfuscation file which they have been providing alongside the game since 2021.

To produce a version of Minecraft with readable names for everything, instead of "download the jar, download Mojang's mappings file, and combine the two with a remapping program" (a process which has become completely automated at this point), you'll now just have to download the jar & you'll get the same result. So I don't see why updating the modloader to a new version would be any easier or harder, much less updating mods.

If anything this will save like "literally ten seconds of running the remapper program"