Luckily I have never had to deal with obfuscation, but from what I have seen there are some grotesque things like defining every single randomly named method call in an array or map with random order or weirdly combining or tearing apart methods.
The only time I encountered it was when I was working for the government, we were working on the rules that decide who gets audited in depth by the tax police. The .jar it compiled to was obfuscated.
My decade-old recollection is also that Minecraft's obfuscation didn't do anything structural, just mangled class and method names. Think of it more like JavaScript minification than a serious attempt to thwart reverse engineering.
Minecraft - like most Java games - just used Proguard. It renames classes/fields/methods and sometimes inlines private methods, but doesn't make any substantial changes to control flow.
I have seen =tons= of obfuscation (non-minecraft). Back in the late 90s it used to be popular, unfortunately.
Most of the stuff is like naming every method a or b, and using the fact they are overloaded, given one-letter-name or a reserved keyword like 'if' to classnames (or packages) was popular, too. Pretty much constant pool modifications w/o too much byte-code-editing.
Overall cheap and unnecessary and has not stopped anyone.
It's still pretty popular. Most large smartphone applications are obfuscated to some degree. At least for Android, because it's bytecode for a VM, it's still trivial to disassemble and understand what is happening at a high level.
AFAIK it also shortens the names, which might make the jar smaller or make it take less time to do name resolution at runtime. It probably won't be very relevant though, especially after startup.
The files will be a little smaller obscured but it doesn't usually impact much other than RAM usage. The algorithms are all the same. Given the size of methods for being JIT compiled is token based not text size I don't think it even impacts that choice. So expect it to be identical.
same, except for meta space used - the class/variable names don't have pretty much any meaningful impact on java runtime, when the code is JIT'd. Even before (interpret mode) that the className/fields/methods are just references in the constant pool
Probably virtually the same. If I recall, the "obfuscation" was mostly mangling
Luckily I have never had to deal with obfuscation, but from what I have seen there are some grotesque things like defining every single randomly named method call in an array or map with random order or weirdly combining or tearing apart methods.
The only time I encountered it was when I was working for the government, we were working on the rules that decide who gets audited in depth by the tax police. The .jar it compiled to was obfuscated.
My decade-old recollection is also that Minecraft's obfuscation didn't do anything structural, just mangled class and method names. Think of it more like JavaScript minification than a serious attempt to thwart reverse engineering.
Minecraft - like most Java games - just used Proguard. It renames classes/fields/methods and sometimes inlines private methods, but doesn't make any substantial changes to control flow.
I have seen =tons= of obfuscation (non-minecraft). Back in the late 90s it used to be popular, unfortunately.
Most of the stuff is like naming every method a or b, and using the fact they are overloaded, given one-letter-name or a reserved keyword like 'if' to classnames (or packages) was popular, too. Pretty much constant pool modifications w/o too much byte-code-editing.
Overall cheap and unnecessary and has not stopped anyone.
It's still pretty popular. Most large smartphone applications are obfuscated to some degree. At least for Android, because it's bytecode for a VM, it's still trivial to disassemble and understand what is happening at a high level.
For Minecraft it’s just removing names and replacing them with random strings
AFAIK it also shortens the names, which might make the jar smaller or make it take less time to do name resolution at runtime. It probably won't be very relevant though, especially after startup.
The files will be a little smaller obscured but it doesn't usually impact much other than RAM usage. The algorithms are all the same. Given the size of methods for being JIT compiled is token based not text size I don't think it even impacts that choice. So expect it to be identical.
same, except for meta space used - the class/variable names don't have pretty much any meaningful impact on java runtime, when the code is JIT'd. Even before (interpret mode) that the className/fields/methods are just references in the constant pool