You could use an obfuscator. However, it's still possible to get your code if someone has the time and skills. It just makes it harder to read.
You could also encrypt your classes and write a custom ClassLoader which decrypts the classes just before they are loaded in the JVM. However, also this is not secure.
Tushar Goel wrote:...so that no one can decrypt it and read our code.
As mentioned, obfuscation is a better bet if you really need to do that. Obfuscators vary in quality. Some simply change names, so its a fairly trivial exercise to get sensible java code back. The better ones perform functional-invariant bytecode transformations that produce bytecode that cannot be represented as Java source code. You can still read the bytecode, but getting Java code back is much more difficult.
Ultimately the JVM needs to see the bytecode to run your application, so whatever solution you use will have a flaw in it. If the attacker is motivated enough they can work out what your program does.
The most secure solution would be to find a way not to distribute your source code, such as keeping the sensitive code behind a secure webservice.
I may be wrong but I believe proguard performs name mangling. When you decompile the code you get Java source code back but the names are very difficult to follow. However a modern IDE doesn't care about the name mangling, and can also perform automatic refactoring such as renaming. The obfuscation will slow down the attacker, but if they are motivated enough they will be able to get readable source code back by examining the code and performing renaming refactors as they figure out what things do.
How motivated are the people you are protecting against?
Because any code that exists on the client can be looked at by that client.
If people can hack (quite easily) compiled C code (think games) then hacking obfuscated Java byte code is going to be a breeze.
You guys wanna see my fabulous new place? Or do you wanna look at this tiny ad?