Some time ago, in my work I needed to protect some classes against other people to read the code. For that purpose, I created a EncryptedClassLoader, that loaded previously
We use the JarProtector library to encrypt our jar files. No obfuscation, but only encryption. There is no option to change the encryption key, but defineClass() will never be called.
Encryption doesn't add much safety to obfuscation. Anyone that is able to run your program will also be able to dump the decypted bytecode to disk. I assume this is why encrypting the bytecode isn't very common, where signing it is for example.
If you do want to encrypt your bytecode, make sure you also obfuscate it and I think the method you are currently using would work just fine without adding any frameworks or libraries.
Short answer, you can't. Encryption doesn't work. Here's an oldish article about why it's pointless to use an encrypted class loader:
Unfortunately, you would be wrong, both in thinking that you were the first to come up with this idea and in thinking that it actually works. And the reason has nothing to do with the strength of your encryption scheme.
You can obfuscate it, but that will only go so far, and in the end I'm a firm believer that your time would be better spend fixing bugs or adding features.
The only way you can protect your code is simply to not allow the user to run it. Instead of distributing an application, sell access to an online service. Your code is then sat on a server and the only thing you're exposing is the interface.
The alternative is to protect your code with contracts and lawyers, but unless you wrote something really good then this is going to cost you more than the revenue you'd otherwise have lost.
You can try VLINX Java Protector, it makes a native ClassLoader by modify JVM to encrypt and decrypt the class data, not the ClassLoader written in Java, can effectively protect your java code