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

281–290 of 478 posts

Re: Minecraft removing obfuscation in Java Edition

#281

Post by creatonez »

xp84 wrote: post #120
1313ed01 wrote: post #70

Earlier quoted context omitted.

I am terrified by Minecraft mods always being distributed from dodgy download sites and not rarely come with their own Windows EXE installers. And as far as I know there is no sandboxing at all in the game (uhm, no pun intended) so once installed the mod has full access to your computer?

As someone whose kid has pulled me into the world of using mods (though not (yet) making them for Java Edition) I think this PSA is worth sharing of how to use minecraft mods without pain and with minimal risk, in case anyone is getting started, or has gotten started and finds it frustrating: 1. Use MultiMC to manage instances with various mods, since mods are rarely compatible with each other, and since each version…

> 3. Curseforge's website and modrinth both seem to be legit places to get mods from. I personally find the installable Curseforge program itself to be bad and spammy, and would never use that, but the site still lets you directly download the jars you need, and lets you check "Dependencies" to find out what other mods you need.

PrismLauncher, a popular MultiMC fork, has direct integration with Curseforge and Modrinth, while being completely ad-free. Best of both worlds.

A few mods are not available because Curseforge allows mod authors the option to force ad monetization by blocking API access, but these are few and far between.

Re: Minecraft removing obfuscation in Java Edition

#282

Post by saagarjha »

mort96 wrote: post #274
saagarjha wrote: post #271

Earlier quoted context omitted.

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.

At runtime this is going to be a branch instruction yes

Re: Minecraft removing obfuscation in Java Edition

#283

Post by mike_hearn »

Quekid5 wrote: post #150
beachy wrote: post #137

Earlier quoted context omitted.

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…

> I can't imagine building something like a graphics framework without some subtyping. While React technically uses some OOP, in practice it's a pretty non-OOP way do UI. Same with e.g. ImGUI (C++), Clay (C). I suppose for the React case there's still an OOP thing called the DOM underneath, but that's pretty abstracted. In practice most of the useful parts of OOP can be done with a "bag/record of functions". (Though…

React is a kind of strange dysfunctional OOP pretending not to be, to appeal to people like those on this thread ;)

Function calls have state, in React. Think about that for a second! It totally breaks the most basic parts of programming theory taught in day one of any coding class. The resulting concepts map pretty closely:

• React function -> instantiate or access a previously instantiated object.

• useState -> define an object field

• Code inside the function: constructor logic

• Return value: effectively a getResult() style method

The difference is that the underlying stateful objects implemented in OOP using inheritance (check out the blink code) is covered up with the vdom diffing. It's a very complicated and indirect way to do a bunch of method calls on stateful objects.

The React model doesn't work for a lot of things. I just Googled [react editor component] and the first hit is https://primereact.org/editor/ which appears to be an ultra-thin wrapper around a library called Quill. Quill isn't a React component, it's a completely conventional OOP library. That's because modelling a rich text editor as a React component would be weird and awkward. The data structures used for the model aren't ideal for direct modification or exposure. You really need the encapsulation provided by objects with properties and methods.

Re: Minecraft removing obfuscation in Java Edition

#284

Post by Pannoniae »

userbinator wrote: post #90
NelsonMinar wrote: post #51

It's extraordinary to me that Minecraft is both the game that has the most robust mod community out there and that the modders were working from obfuscated, decompiled Java binaries. With elaborate tooling to deobfuscate and then reobfuscate using the same mangled names. For over a decade! What dedication.

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.

Yeah, I honestly think that the thing which would kill modding in the future won't be any kind of (overtly) hostile action, it will simply be sheer inertia. Since the new "drop" system, pretty much every minor version requires rewriting many things in your mod, and modders find it hard to keep up, and there will be point when many mods just don't bother updating to the newest version.

The game used to be simple, both conceptually and codewise but obviously, it became more and more bloated the more developers touched it and the more bureaucracy was added. Now, it's a complete nightmare, and I bet it's also a nightmare for the developers too, considering how hard it is for them to fix even basic issues which have been in the game for like a decade at this point.

Re: Minecraft removing obfuscation in Java Edition

#285

Post by mike_hearn »

hyghjiyhu wrote: post #131
nightpool wrote: post #112

Earlier quoted context omitted.

That's definitely true, and I think that's a testament to Minecraft / Java's strong OO design—it dovetails very nicely with the Open/Close principle. However my view is that for a mod to be a mod, there's always going to be stuff that you can't/shouldn't implement just with datapacks—whether that's complex rendering features, new entity logic, or whatever. The Mixin processor makes it really easy to build these kinds…

These tools sound very powerful, could they find use for other Java codebases?

Other codebases don't tend to need those tools, because they already use frameworks like Spring or Micronaut which have such features built-in. Usually without bytecode rewriting and with more concern given to API definition.

For example, in Micronaut (which is what I'm more familiar with) you can use @Replace or a BeanCreatedListener to swap out objects at injection time with compatible objects you provide. If a use-site injects Collection you can just implement that interface yourself, annotate your class with @Singleton or @Prototype and now your object will appear in those collections. You can use @Order to control the ordering of that collection too to ensure your code runs before the other implementations. And so on - there's lots of ways to write code that modifies the execution of other code, whilst still being understandable and debuggable.

Re: Minecraft removing obfuscation in Java Edition

#286

Post by BlackFly »

taneq wrote: post #228
stirfish wrote: post #216

Earlier quoted context omitted.

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

OK yeah that's a pretty good general principle. You think you only need one of these? Are you absolutely certain? You SURE? Wrong, you now need two. Or three.

A singleton is more than just, "I only need one of these," it is more of a pattern of "I need there to be only one of these," which is subtly different and much more annoying.

Re: Minecraft removing obfuscation in Java Edition

#287

Post by q2dg »

kragen wrote: post #21
giancarlostoro wrote: post #6

I wonder if they'll ever just open source the Java Edition on GitHub. People will buy Minecraft on every platform it is released on, just like Skyrim.

It sounds like you might be looking for Minetest/Luanti.

Exactly. Why losing the time with Minecraft when there's Luanti, a free community-driven project?

Re: Minecraft removing obfuscation in Java Edition

#288

Post by StopDisinfo910 »

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…

It’s all about the data model and the architecture.

I think people focus a lot on inheritance but the core idea of OO is more the grouping of values and functions. Conceptually, you think about how methods transforms the data you are manipulating and that’s a useful way to think about programs.

This complexity doesn’t really disappear when you leave OO language actually. The way most complex Ocaml programs are structured with modules grouping one main type and the functions working on it is in a lot of way inspired by OO.

Re: Minecraft removing obfuscation in Java Edition

#289

Post by swiftcoder »

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

Proguard was heavily influenced by the needs of early Android devices, where memory was at a real premium. Reducing the size of static tables of strings is a worthwhile optimisation in that environment

Re: Minecraft removing obfuscation in Java Edition

#290

Post by zimpenfish »

tmtvl wrote: post #75
xboxnolifes wrote: post #55

Earlier quoted context omitted.

The music and sounds play a large part into the experience though, and are much harder to replace than the textures.

The sounds maybe, but the music? If there's one game whose music I always turn off instantly it's Minecraft. Touhou Youyoumu Minecraft ain't.

> If there's one game whose music I always turn off instantly it's Minecraft.

I turn it off but only because I have great difficulty with multiple sound sources at the same time. I will happily listen to C418's output for hours whilst doing something else.

(And also Touhou because who doesn't love an electric trumpet?)

Post reply on HN