Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs
As described in last month's "Under the Hood," you can prevent code loaded by different class loaders from interfering with one another inside the JVM by using a class-file verifier. But to protect assets external to the Java virtual machine, you must use a security manager. The security manager defines the outer boundaries of the sandbox. (For a refresher on the Java sandbox, see the first section of my August "Under the Hood" column.)
A security manager is any class that descends from class
java.lang.SecurityManager. Because they are written in Java, security managers are customizable. A security manager allows you to establish a custom
security policy for an application.
The Java API enforces the custom security policy by asking the security manager for permission to take any action before it
does something that potentially is unsafe. For each potentially unsafe action, there is a method in the security manager that
defines whether or not that action is allowed by the sandbox. Each method's name starts with "check," so, for example,
checkRead() defines whether or not a thread is allowed to read to a specified file, and
checkWrite() defines whether or not a thread is allowed to write to a specified file. The implementation of these methods is what defines
the custom security policy of the application.
Most of the activities that are regulated by a "check" method are listed below. The classes of the Java API check with the security manager before they:
Because the Java API always checks with the security manager before it performs any of the activities listed above, the Java API will not perform any action forbidden under the security policy established by the security manager.