首先，如果您“仅”针对 Windows 市场，那么有一个非常容易防止“.class 到 .java”反编译的方法：使用像 Excelsior Jet 这样的工具来转换.jar in an .exe.
这是万无一失的：它是不可能的如果您使用 Excelsior Jet 来取回 .java 文件（对于所有说“不可能阻止反编译的人来说，这是不可能的”）.class文件”）。当然，攻击者可以启动SoftIce并尝试追踪你的.exe但这比使用 JAD 反编译要棘手一些.class to a .java它肯定不允许找到.java文件返回。
现在，也许您也瞄准了 OS X 和 Linux，或者您没有足够的钱购买 Excelsior Jet。
我正在编写一个用 Java 编写的商业软件。该软件只有在有互联网连接的情况下才有意义。因此，我们通过在服务器端进行部分计算来“保护”我们的软件：我们有几个.class除非它们是从服务器端生成的，并且我们将它们通过网络发送（而通过网络发送的是always不同：我们正在创造独特的、一次性的.class服务器端的文件）。
这需要互联网连接，但如果用户不喜欢我们软件的工作方式，那么他可以随意购买我们竞争对手的劣质产品；）
反编译不会有多大好处：您需要主动破解该软件（即重现服务器端发生的情况），否则您将无法使用它。
我们使用我们自己的“字符串混淆”before我们使用 Proguard。我们还进行源代码检测（我们也可以进行字节码检测），从代码中删除很多内容（例如我们注释掉的“断言”）并引入一些随机的“代码流混淆”[软件可以采取不同的路径却得到相同的结果，这确实使软件难以追踪]）。
然后，我们使用 Proguard（免费）来展平所有 OO 层次结构并混淆已经代码流和字符串混淆的代码。
所以我们的流程是：
- 字符串混淆
- 随机代码流混淆
- Proguard
- final .jar这取决于.class它们是在服务器端（以不同方式）动态生成的。
除此之外，我们还发布非常定期（和自动）的更新，始终确保稍微修改我们的客户端/服务器保护方案（以便每次发布时，假设的攻击者都必须从头开始）。
当然，认输并思考会更容易：“我无法做任何事情来让攻击者的日子更难过，因为 JAD 无论如何都可以找回 .java 文件”（如果您使用 .class 到 .exe 转换器来保护 .class 不被反编译，这是非常有争议的并且是公然错误的）。
