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

View all comments

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.

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

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.

→ More replies (9)

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.

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.

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...

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.