Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Minecraft removing obfuscation in Java Edition

minecraft.net

Post reply on HN
Print view View original

271–280 of 478 posts

Re: Minecraft removing obfuscation in Java Edition

#271

Post by saagarjha »

mort96 wrote: post #270
the_hoser wrote: post #175

Earlier quoted context omitted.

One of the biggest optimizations it offers is shrinking the size of the classes by obfuscating the names. If you're obfuscating the names anyway, there's no reason that the names have to be the same length. "hn$z" is a heck of a lot smaller than "tld.organization.product.domain.concern.ClassName"

So we're not talking about runtime performance, but some minor improvement in loading times? I assume that once the JVM has read the bytecode, it has its own efficient in-memory structures to track references to classes rather than using a hash map with fully qualified names as keys

The names need to be stored somewhere because they are exposed to the program that way

Re: Minecraft removing obfuscation in Java Edition

#272

Post by saagarjha »

astrange wrote: post #113
bayarearefugee wrote: post #104

Earlier quoted context omitted.

[flagged]

One thing I always notice about this kind of post is that it never only has one accusation of oppressing a demographic group. There's always three of them at once. Makes it feel lightweight I think.

Turns out people who are like that rarely constrain it to one demographic.

Re: Minecraft removing obfuscation in Java Edition

#273

Post by mike_hearn »

athrowaway3z wrote: post #260
locknitpicker wrote: post #230

Earlier quoted context omitted.

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

We're talking about OO Java. You bring up shared libraries, list a bunch of things not unique to Java nor OO, then claim `etc.` benefits. You really haven't argued anything, so ending on a "you must be personally blind jab" just looks dumb.

It's because the concepts are the same, but people get enraged by the words. What Java calls a factory would be a "plugin loader" in C++. It's the same concept. And most big C++ codebases end up inventing something similar. Windows heavily uses COM which is full of interfaces and factories, but it isn't anything to do with Java.

Java I think gets attacked this way because a lot of developers, especially in the early 2000s, were entering the industry only familiar with scripting languages they'd used for personal hobby projects, and then Java was the first time they encountered languages and projects that involved hundreds of developers. Scripting codebases didn't define interfaces or types for anything even though that limits your project scalability, unit testing was often kinda just missing or very superficial, and there was an ambient assumption that all dependencies are open source and last forever whilst the apps themselves are throwaway.

The Java ecosystem quickly evolved into the enterprise server space and came to make very different assumptions, like:

• Projects last a long time, may churn through thousands of developers over their lifetimes and are used in big mission critical use cases.

• Therefore it's better to impose some rules up front and benefit from the discipline later.

• Dependencies are rare things that create supplier risks, you purchase them at least some of the time, they exist in a competitive market, and they can be transient, e.g. your MQ vendor may go under or be outcompeted by a better one. In turn that means standardized interfaces are useful.

So the Java community focused on standardizing interfaces to big chunky dependencies like relational databases, message queuing engines, app servers and ORMs, whereas the scripting language communities just said YOLO and anyway why would you ever want more than MySQL?

Very different sets of assumptions lead to different styles of coding. And yes it means Java can seem more abstract. You don't send queries to a PostgreSQL or MySQL object, you send it to an abstract Connection which represents standardized functionality, then if you want to use DB specific features you can unwrap it to a vendor specific interface. It makes things easier to port.

Re: Minecraft removing obfuscation in Java Edition

#274

Post by mort96 »

saagarjha wrote: post #271
mort96 wrote: post #270

Earlier quoted context omitted.

So we're not talking about runtime performance, but some minor improvement in loading times? I assume that once the JVM has read the bytecode, it has its own efficient in-memory structures to track references to classes rather than using a hash map with fully qualified names as keys

The names need to be stored somewhere because they are exposed to the program that way

They have to be stored somewhere, but they don't have to be what the JVM uses when it e.g performs a function call at runtime. Just having the names in memory doesn't slow down program execution.

Re: Minecraft removing obfuscation in Java Edition

#275

Post by mort96 »

voxic11 wrote: post #207
the_hoser wrote: post #175

Earlier quoted context omitted.

One of the biggest optimizations it offers is shrinking the size of the classes by obfuscating the names. If you're obfuscating the names anyway, there's no reason that the names have to be the same length. "hn$z" is a heck of a lot smaller than "tld.organization.product.domain.concern.ClassName"

Yeah in some ways the obfuscation and mappings are similar to minification and sourcemaps in javascript.

And minification in JavaScript only reduces the amount of bytes that has to be sent over the wire, it doesn't improve runtime performance.

Re: Minecraft removing obfuscation in Java Edition

#276

Post by bob1029 »

Obfuscating Minecraft code doesn't make much sense to me from an IP protection angle. It is one of the easier games to build from scratch once you see how it plays. Most of the magic is emergent behavior between many simple rule systems. Nothing in that source code would be much of a revelation. It's not like there's a nanite implementation hiding in there somewhere. It's mostly boring stuff like defining how pig or sheep walk through the scene and respond to various goals. The "scariest" part of Minecraft tech is probably chunk management.

Re: Minecraft removing obfuscation in Java Edition

#277

Post by creatonez »

LelouBil wrote: post #92
nightpool wrote: post #83

Earlier quoted context omitted.

Not only working around proguard, but Minecraft mods are built on top of an incredibly cool and flexible runtime class file rewriting framework that means that each JAR can use simple declarative annotations like @Inject to rewrite minecraft methods on the fly when their mod is loaded or unloaded. This massively revolutionized mod development, which was previously reliant on tens of thousands of lines of manually com…

The devs for Java Edition really have mods in mind nowadays. - They left in the code debug features that they used to strip out. - They left in the code their testing infrastructure that they used to strip out as well. - They started making everything namespaced to differentiate contents between mods (like in this week's snapshot they made gamerules namespaced with the "minecraft:" prefix like items and blocks and wh…

You still need quite a lot of mixins / modified code to actually do useful things. Mojang isn't always making things unnecessarily extensible, just extensible enough for them to keep updating the game.

Re: Minecraft removing obfuscation in Java Edition

#278

Post by SirGiggles »

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…

This is deliberate misinformation.

You can easily see that versions prior to Beta 1.8 were obfuscated just by downloading the .jar for the older versions on minecraft.wiki.

You can even view some of the old MCP mappings here: https://archive.org/details/minecraftcoderpack

Re: Minecraft removing obfuscation in Java Edition

#279

Post by mike_hearn »

tormeh wrote: post #254
qwertytyyuu wrote: post #231

Earlier quoted context omitted.

That's why we use depedency injection now~~!

I've always wanted my editor's go-to functionality to take me to an abstract class instead of the place where the actual logic resides. Good times.

Any modern IDE will let you immediately bring up the subclasses with a single hotkey. If you have an abstract class with only a single subclass and that's not because new code is going to be added soon then yes, it's a bad design decision. Fortunately, also easy to fix with good IDEs.

Re: Minecraft removing obfuscation in Java Edition

#280

Post by com2kid »

stirfish wrote: post #216
taneq wrote: post #177

Earlier quoted context omitted.

You gotta admit, though, that a language which strongarms you into writing classes with hidden state and then extending and composing them endlessly is kinda pushing you in that direction. It’s certainly possible to write good code in Java but it does still lend itself to abuse by the kind of person that treated Design Patterns as a Bible.

>kind of person that treated Design Patterns as a Bible I have a vague idea of what the Bible says, but I have my favorite parts that I sometimes get loud about. Specifically, please think really hard before making a Singleton, and then don't do it.

Singletons are so useful in single threaded node land. Configuration objects, DB connection objects that have connection pooling behind them, even my LLM connection is accessed via a Singleton.
Post reply on HN