Mixin VS bytecode-viewer

And one day maybe you'll need that to inject code into specific location, but it's to do advanced things: https://github.com/SpongePowered/Mixin/wiki

SpongePowered isn't a Mod, they're the group that maintain the Framework for Mixins. The next mod in the stacktrace is cpw.mods.modlauncher

That source was probably outdated. Forge didn't natively allow you to do that. You could do Java voodoo to allow a library that implemented(? Not sure if it implemented the feature or simply allowed it to be used in a specific way) Mixins, those allow you to modify the game's bytecode. Modern Forge has that library natively. Source: First paragraph of https://github.com/SpongePowered/Mixin/wiki/Mixins-on-Minecraft-Forge

These days Mojang provides obfuscation maps, so you can work with proper class and method names (though no parameter or local variable names). There's also been a lot of effort been put into the tooling. Nowadays there exists Gradle plugins that will download the game jar, decompile it and deobfuscate it using the official mappings. You develop against the deobfuscated code, then the plugin will turn the unobfuscated names back into their obfuscated versions when you compile. There's also been technology developed that lets you easily modify specific parts of a method in the game, so you can e.g. insert calls to your own functions at runtime.[1] This saves from you having to modify the game jar itself.

[1]: https://github.com/SpongePowered/Mixin

quilt (and fabric) take mojang's jar and preprocess it similarly, but the rest of the modifications to the code are done at runtime using a ridiculously powerful instrumenting classloader. the game is not decompiled at all, other than giving you something to look at in the IDE.

If you can't use the API, I suggest you to use Mixins or really asking yourself if your idea should worth the instability/effort of creating a coremod.

see spongepowered's mixin wiki

I think they forgot to google translate the disadvantages of JEB Decompiler

I haven't used JEB to comment, but I've gotten a lot of mileage out of https://github.com/pxb1988/dex2jar#readme and then feed the normal Java jars it produces into https://github.com/mstrobel/procyon#readme and (of course) one shouldn't overlook picking your favorite tool for dealing with AndroidManifest.xml which often has fun things hiding in it

While digging up those links, I was reminded that some folks enjoy https://github.com/Konloch/bytecode-viewer#is-there-a-demo because it can be easier to "try out" a few of the decompilation engines, but I don't use it because it's hard to do batch things with it, versus dex2jar into procyon is automation friendly

Here's a good tool for inspecting the bytecode of applications, with built in decompiler support: https://github.com/Konloch/bytecode-viewer

If you're curious what anything (Lombok or otherwise) compiles to, JVM bytecode is much simpler than the kinds C/C++ compiles to. It's fairly readable even with the JDK disassembler javap. There are also various community disassemblers and decompilers that provide nicer output than javap. I use https://github.com/Konloch/bytecode-viewer, which is a GUI frontend for several. If one decompiler doesn't handle a class well, another usually does.

I use Bytecode Viewer, https://github.com/Konloch/bytecode-viewer with Dark Mode.

if you do use this plugin i'd recommend also using https://bytecodeviewer.com/ to check the supposed malicious lines of code.

Take a look at tools like this one to get an idea of what you can actually get: https://bytecodeviewer.com/

Also, you can always install the latest release and then put it through a Java decompiler to get the complete source code. It might have some errors since decompilers aren't perfect, but will give you a more complete source code than anything I can legally provide.