n this installment in our series, we further examine the elements that should be part of a secure Java code policy, including such safeguards as compartmentilization and cryptography. In our last installment, we introduced policy and covered product requirements, error handling, . . .
n this installment in our series, we further examine the elements that should be part of a secure Java code policy, including such safeguards as compartmentilization and cryptography. In our last installment, we introduced policy and covered product requirements, error handling, and object states. Part two will finish discussing elements that should be part of a secure Java code policy.

Sensitive information refers mainly to passwords, algorithms, and cryptographic keys, but could mean any sort of information a product uses that is not intended for an end user to see. Ideally, this kind of data should never be hard-coded, or put into permanent memory, which can be difficult, because some of Java's other security features, such as automatic garbage collection.

The link for this article located at EarthWeb is no longer available.