The OWASP Java Project was launched a few months ago with the goal of providing security resources to the Java community. The project already has a number of articles that could be of use to those interested in building or deploying secure Java applications, including: - Declarative Access Control in Java - Hashing in Java - How to add validation logic to HttpServletRequest - How to perform HTML entity encoding in Java - JAAS Timed Login Module - JAAS Tomcat Login Module - Java Security Resources - Preventing LDAP Injection in Java - Preventing SQL Injection in Java - Securing Tomcat - Using JCaptcha Ideas or content for articles can be submitted to the wishlist or the project's roadmap.

If i run a product company and i dont want my clients to just de compile my code and start using it - how do i prevent that ? Is there any security i can apply on top of my soruce code so its not decompilable ? I know there is obfuscation or a better licensing policy. Well the later doesnt really work in most cases especially when i run a small company. But obfuscation is the only way ?

If i run a product company and i dont want my clients to just de compile my code and start using it - how do i prevent that ?
Is there any security i can apply on top of my soruce code so its not decompilable ?

I know there is obfuscation or a better licensing policy. Well the later doesnt really work in most cases especially when i run a small company. But obfuscation is the only way ?

This might be overkill, but I've used encrypted class files before, and a decrypting classloader.

This might be overkill, but I've used encrypted class files before, and a decrypting classloader.

And how do you prevent your decrypting classloader from being decompiled? Or better yet, how do you prevent it from being run in a JVM with a modified rt.jar on the boot class path where java.lang.ClassLoader.defineClass() is "customized" so it neatly dumps all bytecode it receives to a directory in the local filesystem? Obfuscation and encryption are both quite futile. You can slow down a reverse engineering attempt, but you won't prevent it.

This might be overkill, but I've used encrypted class files before, and a decrypting classloader.

And how do you prevent your decrypting classloader from being decompiled?

Or better yet, how do you prevent it from being run in a JVM with a modified rt.jar on the boot class path where java.lang.ClassLoader.defineClass() is "customized" so it neatly dumps all bytecode it receives to a directory in the local filesystem?

Obfuscation and encryption are both quite futile. You can slow down a reverse engineering attempt, but you won't prevent it.

So no real solution as such to prevent your intellectual property if you build it and sell it in java ?

No I don't think there is an absolute method of protecting IP in a standalone Java application. But obfuscation will slow down the decompiling process. Other alternatives are: - Do the clever stuff on a server - Do the clever stuff in native code All depends on how important IP is to you, and how likely it is that someone would go to the trouble of stealing it.