Tell me one good reason why anyone would despise dynamic class loading in Java. Chances are that no one will. Neither did I, until I reached a point where I could not contain my despair seeing it being much used and abused. RMI is an inherent evil. Say that to a group of Java programmers and try staying there a while. These guys have developed extremely flexible and robust network applications exploiting the clout of dynamic class loading.

Well RMI is good as an optimal distributed solution, but invoking runtime instances from an arbitrary VM of different security context may compromise the object integrity to some extent. Not always, unless you adopt to secure transport over RMI. A convenient solution is to sign the object and seal it with a key, which can be made available at the decrypting VM. There is a widespread misconception about these two really non morbid classes 'SealedObject' and SignedObject' in Java. And developers often ask around for suggestions as when to seal and when to sign an object. As far as I concede, signing an object just guarantees data integrity. But sealing an object offers data confidentiality.

In this month's code stack, we shall create a self signing class, which signs its own object with a generated private key and later seals that with a secret key. This sealed object can be serialized and passed across VMs, where the consumer can decrypt the object with the same secret key and can verify the data integrity with the public key. At least now the object authenticity is as good as the cryptographic algorithm used and not left to the amity of the transit methods.

And remember; do not sign a sealed object. But seal a signed object. Though you can do either way, signing an encrypted object is sometimes dangerous. Typical usage of this method is when your application gets started, it can decrypt and verify the object before switching back to previously saved state.

• Source Code