首先，如果你的目标“只” Windows的市场有一个非常简单的防止“的.class来的.java”编译：使用像怡东喷气一种工具，将改变 的.jar 中的
.exe文件 。
这是万无一失的：如果您使用Excelsior Jet ，则 无法 取回.java文件（对于所有人来说，这么长的时间说：“无法防止反编译
.class 文件”）。当然，攻击者可以启动 SoftIce 并尝试跟踪您的 .exe， 但是比起使用JAD将 .class 反编译为
.java来说 ，这将变得有些棘手，并且当然不允许找回 .java 文件。
现在也许您也以OS X和Linux为目标，或者没有足够的资金来使用Excelsior Jet。
我正在写用Java编写的商业软件。仅当有Internet连接时，该软件才有意义。因此，我们通过在服务器端进行部分计算来“保护”我们的软件，其中包括：我们有几个
.class ，除非它们是从服务器端生成的，否则它们将无法工作，并且我们将它们通过有线发送（而且网上发送的内容 总是
不同的：我们正在服务器端生成唯一的一次性 .class 文件）。
这需要Internet连接，但是如果用户不喜欢我们软件的工作方式，那么他可以自由购买我们竞争对手的劣等产品；）
反编译并不会带来太多好处：您积极地需要破解软件（例如，再现服务器端发生的事情），否则将无法使用它。
在 使用Proguard 之前， 我们先使用自己的“字符串混淆”
。我们还进行源代码检测（我们也可以完成字节码说明），其中从代码中删除了很多内容（例如我们注释掉的“断言”），并引入了一些随机的“代码流混淆”（该软件可以不同的路径却获得了相同的结果，这确实使软件难以跟踪]。
然后，我们使用Proguard（免费）来展平我们所有的OO层次结构，并混淆已被代码流和字符串混淆的代码。
所以我们的流程是：
- 字符串混淆
- 随机码流混淆
- 保卫者
- 最终 .jar 取决于 .class （在服务器端（不同）动态生成）。
除此之外，我们还发布了非常定期（自动）的更新，该更新始终确保一定程度地修改了我们的客户端/服务器保护方案（因此，每次发布时，虚伪的攻击者都必须从头开始）。
当然，更容易投入思考： “我无法采取任何措施使攻击者的生活更加艰难，因为JAD仍然可以找到.java文件。”
（这很容易引起争议，并且在以下情况下公然地错了：您使用.class到.exe转换器来保护.class免受反编译）。
