1〉针对windows平台客户

可以考虑使用商用软件如 Excelsior Jet 将你的程序.jar文件转化为一个可执行文件(.exe).

This is foolproof: it is impossible to get the .java file back if you use Excelsior Jet (so long for all the people saying "it's impossible to prevent decompilation of a .class file"). Sure, an attacker could launch SoftIce and try to trace your .exe but that will prove a bit trickier than using JAD to decompile the .class to a .java and it certainly won't allow to find the .java file back.

2>平台独立性 包括 OS X and Linux ，并不想花钱买商用软件 Excelsior Jet.

一种方法是让程序只用能连接到互联网的环境中使用，这样可以通过在线检测的方法来保护您的程序，这样可以通过设计成服务端和客户端安装模式，让部分程序功能必须通过服务端产生，通过网络发送到客户端的形式来保护。

I'm writing a commercial software written in Java. That software only makes sense if there's an Internet connection. Hence we "protect" our software, amongst other, by having part of the computation happening on the server side: we have several .class that won't work unless they're generated from the server side and we send them down the wire (and what is sent on the wire is always different: we're generating unique, one-off .class files on the server side).

如果你的客户不满意必须借助互联网环境的运行方式，当然可以让他们选择通过购买商用软件的方式来保护。

This requires an Internet connection but if the user doesn't like how our software works then he's free to buy one our competitor's inferior product ;)

Decompiling will not do much good: you actively need to crack the software (ie reproduce what is happening on the server side) or you won't be able to use it.

另一种更实际的方法是通过“模糊”Java类文件，同时引入字节流乱码处理，处理之后再通过Proguard处理，改变这个程序框架，去除面向对象架构来模糊化程序的逻辑和字符处理。最终的jar包还需依赖服务端发送过来的java类，这样程序的架构基本失去原样，即使被破解，可维护性极差。

We use our own "string obfuscation" before we use Proguard. We also do source code instrumentation (we could have done bytecode instrumenation as well) where we remove lots of things from the code (like the "assert" that we comment out) and introducesome random "code flow obfuscation" [the software can take different paths yet obtain the same result, this is something that really makes the software hard to trace]).

Then we use Proguard (which is free) to flatten all our OO hierarchy and to obfuscate the already-code-flow-and-string-obfuscated code.

So our flow is:

• string obfuscation
• random code flow obfuscation
• Proguard
• final .jar that depends on .class that are (differently) dynamically generated on the server side.

In addition to that we release very regular (and automated) update which always make sure to modify a bit our client/server protection scheme (so that with each release an hypotethical attacker has to start mostly from scratch).

Of course it's easier to throw the towel in and to think: "there's nothing I can do to make an attacker's life harder because JAD can find back the .java file anyway" (which is more than very debatable and blatantly wrong in the case where you usea .class to .exe converter to protect your .class from decompiling).