Java bytecode is trivially decompilable with tools like JD-GUI and Fernflower. Our Java obfuscator applies string pooling, anti-decompile bytecode patterns, and field renaming to make decompilation impractical.
Joker protects Java and JAR files by encrypting compiled classes and loading them through a small runtime loader, so static decompilers see encrypted blobs instead of source. String encoding, field renaming, and debug stripping remove the remaining hints, and it is validated on real Spigot and Paper plugins. Java is the one Joker language protected by layered class encryption rather than a bytecode VM.
Java bytecode is high level and self-describing, which is why JD-GUI, CFR, and Fernflower reconstruct readable source so easily. Renaming-only tools such as ProGuard shrink and rename, but what comes out the other side of a decompiler is still recognizably your program, with your strings, your control flow, and your intent intact. Encryption changes what the decompiler even gets to look at.
All strings moved out of plain literals into a pooled, encoded class, reached through indirection instead of readable constants. The decoder ships in the file, so this defeats casual decompilation rather than guaranteeing secrecy.
Synthetic flags, duplicate fields, garbage attributes, and fake signatures that crash decompilers like JD-GUI.
Private fields renamed to unreadable identifiers. Reflection-aware, won't break Bukkit/Spigot plugins.
Source file names, line numbers, and local variable tables removed. Stack traces no longer map back to your source.
Renaming versus encryption for JVM code.
| Typical tools | Joker | |
|---|---|---|
| Core technique | Rename and shrink | Class encryption plus renaming |
| After decompilation | Readable-ish logic | Encrypted blobs, no logic |
| Strings | Often plaintext | Pooled and encoded |
| Debug info | May remain | Stripped (files, lines, locals) |
| Spigot/Paper | Supported | Tested, reflection-aware |
Drag and drop your file into the dashboard or use our Discord bot.
Select light, medium, or heavy protection based on your needs.
Get your obfuscated file with unique VM encryption. Ready to deploy.
Yes. Our Java obfuscator is tested with Spigot plugins. Field renaming is reflection-aware and won't break plugin.yml references.
Java/.jar uploads are temporarily paused for a security review. The other seven languages are unaffected — check back soon for Java.
We've tested with multiple Spigot plugins (Spleef, GlobalLobby, Sprint). Only private fields are renamed, and reflection patterns are detected and preserved.
ProGuard focuses on shrinking and basic renaming. We add string pooling, anti-decompile bytecode patterns, and debug stripping on top of renaming.
It can open it, but what it shows for encrypted classes is the loader and encrypted data, not reconstructed logic, and anti-decompile patterns additionally crash or confuse common decompilers. A determined attacker with runtime access can eventually recover classes; the goal is raising that cost far above casual copying.
No, and we say so plainly. Java protection uses layered class encryption, string pooling, renaming, and debug stripping. The bytecode VM approach covers 7 of Joker's 8 languages; for the JVM, encrypting the classes themselves is the stronger fit.