As we know , there are a lot of java decompiler tools which can convert .class to .java file.
Therefore,we need to protect our .java files against decompiler. I know this is a big topic,and maybe there is no ending.
Usually, there are two ways : obfuscator and customized classloader.
Is there any mature solution or open source framework, which combined those two ways ?
Another aspect is related with exe4j, which package jars to exe file,seems like it can protect java codes , because what we can see is exe file instead of jars or class files. But indeed, when it runs, it decompose all jars files into temporary directories, that means it is easy to get class files for decompiler. So any considerations for protecting java codes from the aspect of exe4j ?
Thanks for your comments and suggests.
Updating
Thanks everyone for your suggest or experience share. That is helpful to me. To make a conclusion, I will give up any obfuscator or customized classloader with encryption things. Because finally Java codes can be disclosed before clever hackers.
I will remove some core codes during compiler time using tricks like "#ifdef" in C language. In Java, static and final boolean class variable can be used to do the same job. Then the compilered class file will not contain need-protected java codes.
You can't protect the class files from a decompiler and from malicious users. However the output of the decompiler may not be valid java.
The best method is to document your API (assuming this is available for your customers to use) and application very very well. And have your support personnel be able to resolve API and application issues. Then your customers will have no reason to want to use a decompiler to explore why things are not working correctly.
- You can use an obfuscator, like ProGard or Ygard, but it is not too complex to decrypt strings and rename classes, fields and methods.
- You can encrypt your classes with a private key, and use a custom classloader to decrypt your classes with a public key before loading into memory, but it is not too complex to modify the classloader to save onto a disc all the classes loaded.
- You can try crash decompilers. JAD is one of the best decompilers but if you add corrupted entries in the constant pools, all products powered by JAD crash. However, some decompilers are still working.
The only way to protect your software, is to deploy it in a SaaS/PaaS.
But keep one's head: most people use a decompiler because they have a technical problem and the documentation is poor or nonexistent. Write a good documentation and use a solid EULA is the better solution.
Software as a Service.
The only way that's particularly effective is to offer your program as a web service of some kind, so that the compiled code is never even available on an end-user machine.
The next most effective solution, which is one that is widely used in practice, is to make your program so terrible that no-one wants to use it or spend the time reverse engineering it in the first place. I suspect that when this happens it is typically accidental, however.
You can try open source project proguard
In fact, not only Java, silverlight and flash also have the same issue. Anyone who downloaded the package can decompress and then decompile to reverse engineer your code.
I agree with Saas will be the best solution, having the web service to handle all the underlying logic and provides data establishes a relatively secured & isolated layer to the end clients to consume data.
My advice is that if you are really serious about this, you should only release the demo software to people who have signed a legally binding non-disclosure agreement. And be prepared to go to court if they breach the agreement.
By all means, obfuscate your demo application, etc as well, but don't imagine that this will stop a determined hacker from discovering the "secret sauce" in your application. It is not possible to prevent this, in theory and in practice. Piracy is inevitable if you use the pay-for-license model of monetizing your software.
(Actually, it is theoretically possible, but only with a totally secured platform like TPM. And that ain't an option for you. Trust me.)
What about encrypting your class files and using a customised classloader to load your class files ?
Everything is hackable. Just have a solid EULA and put the efforts in there instead of wasting them to hopeless attempts to protect the code.
来源：https://stackoverflow.com/questions/1879061/how-to-protect-java-codes-against-decompiler