Minecraft removing obfuscation in Java Edition • Hacker News Board

Re: Minecraft removing obfuscation in Java Edition

#331

Post by maeln » Thu, Oct 30, 2025, 10:42 AM UTC

Nextgrid wrote: post #174

maeln wrote: post #22

Earlier quoted context omitted.

> I think one of the reasons Vision Pro and metaverse have been struggling is because their engines are bad. Not just locked down, but hard to develop on (although I don't have personal experience, I've heard this about VR in general). If you want to build a community, you must make development easy for hobbyists and small users*. I believe this has held even for the biggest companies, case in point the examples abov…

I think there’s a difference between “indie dev” aka either an experienced SWE trying it or some really motivated person with an established identity, credit card & income stream and a kid/teenager tinkering around. In a “free for all” setting, anyone (including kids) could potentially learn enough (or even just download pre-made scripts) and try their hand at modding software/games. In a modern situation with develo…

The Vision Pro might be pretty lock down, but making a VR app / game on PCVR or on Pico/Meta headset is pretty "free for all"

Re: Minecraft removing obfuscation in Java Edition

#332

Post by bombcar » Thu, Oct 30, 2025, 10:43 AM UTC

creatonez wrote: post #258

Alex4386 wrote: post #215

"Minecraft: Java Edition" has been obfuscated since the release. No, It was obfuscated since around 1.8 when you (Microsoft) buy up Mojang Studios. before that? meh, It wasn't. That's the main reason why JE has broader mod ecosystem from the start., result being 1.7.2 being the one of the most active modded versions since most of them can't get passed to around 1.8. The motive behind this is probably due to them find…

> No, It was obfuscated since around 1.8 when you (Microsoft) buy up Mojang Studios. before that? meh, It wasn't. Huh? This is not true. The very first version released in 2009 was obfuscated with ProGuard, the same obfuscator used today. The reason Minecraft 1.7 was a popular version for modding was because Forge was taking too long to come out, and the block model system was changed in a fundamental way in the next…

1.7.10 is definitely obfuscated, and 1.7 had one of the longest "lifespans" of a Minecraft version.

The best thing to happen to Minecraft is 1.7.10 backporting; the second best thing has been breaking the Forge monopoly on modding.

(The code quality of mods back in the 1.7 days ranges from "pretty decent" to "absolutely horrendous" mind you.)

Re: Minecraft removing obfuscation in Java Edition

#333

Post by achierius » Thu, Oct 30, 2025, 10:46 AM UTC

locknitpicker wrote: post #307

high_na_euv wrote: post #302

Earlier quoted context omitted.

>You cannot have quality software without these basic testing techniques Of course you can, wtf? Mock are often the reason of tests being green and app not working :)

> Of course you can, wtf? Explain then what is your alternative to unit and integration tests. > Mock are often the reason of tests being green and app not working :) I don't think that's a valid assumption. Tests just verify the system under test, and test doubles are there only to provide inputs in a way that isolates your system under test. If your tests either leave out invariants that are behind bugs and regress…

Most compilers do not use "unit" tests per se. Much more common are integration tests targeted at a particular lowering phase or optimization pass.

This is pretty important since "unit tests" would be far too constraining for reasonable modifications to the compiler, e.g. adding a new pass could change the actual output code without modifying the semantics.

Re: Minecraft removing obfuscation in Java Edition

#334

Post by codedokode » Thu, Oct 30, 2025, 10:51 AM UTC

jjmarr wrote: post #226

mywittyname wrote: post #157

Earlier quoted context omitted.

For me, it's the fact that the mess of DAOs and Factories that constituted "enterprise" Java in the 00s was a special kind of hellscape that was actively encouraged by the design of the language. Most code bases don't need dynamically loaded objects designed with interfaces that can be swapped out. In fact, that functionality is nearly never useful. But that's how most people wrote Java code. It was terrible and taug…

It's very useful in C++, funnily enough. This is because I can have a non-templated interface base class, then a templated impl class. Then my templated impl header can be very heavy without killing my build times since only the interface base class is #included. Not sure if this is as common in Java.

Using more complex architecture (which requires more human time to understand) to merely make build time shorter is a ridiculous choice.

Re: Minecraft removing obfuscation in Java Edition

#335

Post by AyanamiKaine » Thu, Oct 30, 2025, 10:56 AM UTC

There is always one thing that I found so facintating with the modding scene in Minecraft. Because Minecraft does not have a modding api but the java byte code can be changed. People simply developed their own way of creating an API. There are 2 main modding APIs. Forge/Neo-Forge and Fabric.

[1]Fabric uses Mix-ins while [2]Forge uses a more event based system that is added to the source code of minecraft where they add hooks into events that users can use.

To me its just incredible. Its not often that I see that users own an abstraction instead of the developers.

I wonder from a modding perspective would it be better if all public methods are just the API users can call and they themselves create a way for mods to exist?

[1] https://wiki.fabricmc.net/tutorial:mixin_introduction [2] https://docs.minecraftforge.net/en/latest/concepts/lifecycle...

Re: Minecraft removing obfuscation in Java Edition

#336

Post by DeathArrow » Thu, Oct 30, 2025, 11:00 AM UTC

beachy wrote: post #137

userbinator wrote: post #90

Earlier quoted context omitted.

More proof that you don't need the source code to modify software. Then again, Java has always been easy to decompile, and IMHO the biggest obstacle to understanding is the "object-oriented obfuscation" that's inherent in large codebases even when you have the original source.

First time I have heard of object-oriented obfuscation. I get it, but in general I don't get the OO hate. It's all about the problem domain imo. I can't imagine building something like a graphics framework without some subtyping. Unfortunately, people often use crap examples for OO. The worst is probably employee, where employee and contractor are subtypes of worker, or some other chicanery like that. Of course in th…

From my pov, both inheritance and encapsulation aren't great if you have to maintain code and add new one.

Also, I dislike design patterns overuse, DDD done Uncle Bob style.

Also we can think of where OOP drives many teams to:

https://steve-yegge.blogspot.com/2006/03/execution-in-kingdo...

https://factoryfactoryfactory.net/

https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...

Re: Minecraft removing obfuscation in Java Edition

#337

Post by codedokode » Thu, Oct 30, 2025, 11:10 AM UTC

locknitpicker wrote: post #307

high_na_euv wrote: post #302

Earlier quoted context omitted.

>You cannot have quality software without these basic testing techniques Of course you can, wtf? Mock are often the reason of tests being green and app not working :)

> Of course you can, wtf? Explain then what is your alternative to unit and integration tests. > Mock are often the reason of tests being green and app not working :) I don't think that's a valid assumption. Tests just verify the system under test, and test doubles are there only to provide inputs in a way that isolates your system under test. If your tests either leave out invariants that are behind bugs and regress…

I personally believe mocks are a bad practice which is caused by bad architecture. When different components are intertwined, and you cannot test them in isolation, the good solution is refactoring the code; the bad is using mocks.

For example of such intertwined architecture see Mutter, a window manager of Gnome Shell (a program that manages windows on Linux desktop). A code that handles key presses (accessibility features, shortcuts), needs objects like MetaDisplay or MetaSeat and cannot be tested in isolation; you figuratively need a half of wayland for it to work.

The good tests use black box principle; i.e. they only use public APIs and do not rely on knowledge of inner working of a component. When the component changes, tests do not break. Tests with mocks rely on knowing how component work, which functions it calls; the tests with mocks become brittle, break often and require lot of effort to update when the code changes.

Avoid mocks as much as you can.

Re: Minecraft removing obfuscation in Java Edition

#338

Post by astrange » Thu, Oct 30, 2025, 11:10 AM UTC

meindnoch wrote: post #303

Retr0id wrote: post #169

Earlier quoted context omitted.

As a reverse engineer, I totally get the phrase. Even with non-obfuscated code, if you're working with a decompilation you don't get any of the accompanying code comments or documentation. The more abstractions are present, the harder it is to understand what's going on. And, the harder it is to figure out what code changes are needed to implement your desired feature. C++ vtables are especially annoying. You can see…

Vtables can be annoying to follow through, but try reverse-engineering an Objective-C binary! Everything is dispatched dynamically, so 99% of the call graph ends in objc_msgSend(). Good luck figuring out what the message is, and the class of the object receiving it.

Isn't that easy? The message is a string in one of the register parameters to it.

> Everything is dispatched dynamically

Well, not everything, there is NS_DIRECT. The reason for that being that dynamic dispatch is expensive - you have to keep a lot of metadata about it in the heap for sometimes rarely-used messages. (It's not about CPU usage.)

Re: Minecraft removing obfuscation in Java Edition

#339

Post by NwpierratorR » Thu, Oct 30, 2025, 11:11 AM UTC

AyanamiKaine wrote: post #335

There is always one thing that I found so facintating with the modding scene in Minecraft. Because Minecraft does not have a modding api but the java byte code can be changed. People simply developed their own way of creating an API. There are 2 main modding APIs. Forge/Neo-Forge and Fabric. [1]Fabric uses Mix-ins while [2]Forge uses a more event based system that is added to the source code of minecraft where they a…

> I wonder from a modding perspective would it be better if all public methods are just the API users can call and they themselves create a way for mods to exist?

It's the way vintage story implemented modding. They developed the whole game as engine + modapi + hooking engine for stuff outside of hookapi.

Then most of gameplay is implemented as mods on top of engine using api and hooking. And those tools are open source, with central distribution point for mods, so servers can dispatch and send update of required mods to clients as they join.

Marvellous and elegant design. Makes running a server with client side mods a breeze, because mods are automatically pushed to the clients.

Though in the end, you can't really open all the interfaces and expect it to be stable without making some huge trade offs. When it works, it's extremely pleasing. Some mods for vintage story that are made purely using mod api can work between major game versions. Even server/client version check is intentionally loose as mismatched versions can still for the most part interact across most of mechanics.

In practice, to preserve balance of api evolution and stability, not everything in the game is in the api, and thus you have to use their hooking api, and stuff that is not exposed tends to break much more often, so mods require manual updates, just like in minecraft(though not as bad, tbh. In minecraft nowadays modders tend to support both fabric and neoforge/forge apis, targeting each for at least a few major versions. In vintage story, you only gotta support one modding api heh).

Re: Minecraft removing obfuscation in Java Edition

#340

Post by lelanthran » Thu, Oct 30, 2025, 11:26 AM UTC

locknitpicker wrote: post #230

mywittyname wrote: post #157

Earlier quoted context omitted.

For me, it's the fact that the mess of DAOs and Factories that constituted "enterprise" Java in the 00s was a special kind of hellscape that was actively encouraged by the design of the language. Most code bases don't need dynamically loaded objects designed with interfaces that can be swapped out. In fact, that functionality is nearly never useful. But that's how most people wrote Java code. It was terrible and taug…

> Most code bases don't need dynamically loaded objects designed with interfaces that can be swapped out. In fact, that functionality is nearly never useful. But that's how most people wrote Java code. Perhaps I'm not following, but dynamically loaded objects are the core feature of shared libraries. Among it's purposes, it allows code to be reused and even updated without having to recompile the project. That's pret…

> > Most code bases don't need dynamically loaded objects designed with interfaces that can be swapped out. In fact, that functionality is nearly never useful. But that's how most people wrote Java code.

> Perhaps I'm not following, but dynamically loaded objects are the core feature of shared libraries. Among it's purposes, it allows code to be reused and even updated without having to recompile the project. That's pretty useful.

> Interfaces are also very important. They allow your components to be testable and mockable. You cannot have quality software without these basic testing techniques. Also, interfaces are extremely important to allow your components to be easily replaced even at runtime.

I don't think GP was saying that Dynamically loaded objects are not needed, or that Interfaces are not needed.

I read it more as "Dynamically loaded interfaces that can be swapped out are not needed".