Firstly, you cannot avoid reverse code conversion. The JVM bytecode should be easy to execute, and there are several programs for reverse engineering it (the same applies to the .NET CLR). You can only make it harder to raise the barrier (i.e. Cost) to see and understand your code.
The obfuscate source is usually used with some tool. Classes, methods and fields are renamed throughout the code base, even with invalid identifiers, if you decide what the code does that is impossible to understand. I have had good results with JODE in the past. After obfuscation, use the decompiler to see what your code looks like ...
Next to obfuscation, you can encrypt your class files (everything except a small start class) using any method, and use an expander for the user class. Unfortunately, the class loader class cannot be encrypted by itself, so people can determine the decryption algorithm by reading the decompiled code of your class loader. But the window to attack your code has become smaller. Again, this does not stop people from seeing your code, but simply makes it harder for a random attacker.
You can also try converting the Java application to some EXE windows that will hide the key that it is Java at all (to some extent) or is really compiled into machine code, depending on your need for JVM functions. (I have not tried this.)
source share