Application Authorization - Expert Oracle and Java Security - page 226

Implement an Inner Class in OracleJavaSecure
For testing purposes in this chapter, we will define an inner class, InnerRevLvlClass , in the
OracleJavaSecure class that implements RevLvlClassIntfc . To generate an inner class, just include the
class definition within an existing class definition. In our case, it looks like Listing 10-20. Inside the body
of the definition for OracleJavaSecure , we declare the inner class, InnerRevLvlClass .
Listing 10-20. OracleJavaSecure Inner Class for Identity and Versioning, InnerRevLvlClass
public class OracleJavaSecure {
…
public static class InnerRevLvlClass
implements Serializable , RevLvlClassIntfc
{
private static final long serialVersionUID = 2011010100L;
private String innerClassRevLvl = "20110101a";
public String getRevLvl() {
return innerClassRevLvl;
}
}
 Note For most of the rest of this chapter, we will be referring back and forth to Java code that you will find in
the file named Chapter10/orajavsec/OracleJavaSecure.java, and to SQL and PL/SQL code that you will find in the
file named Chapter10/AppSec.sql .
Notice that our inner class is designated as public static . The static is not necessary, but assures
us that the class exists when the parent, OracleJavaSecure , is instantiated. On the other hand, the public
designation is significant from a security standpoint. We would prefer to make this inner class private,
and we could for OracleJavaSecure.InnerRevLvlClass . But for other independent applications, the inner
classes will need to be public so that OracleJavaSecure on the Oracle Database can instantiate them.
Our inner class also must implement the Serializable interface (another required element of the
template we provide to our developers.) By implementing Serializable (no methods are required), we
are assuring that we can take our inner class, get the bytes of the object and pass them to Oracle
database for storage. We can only handle objects in that way if they implement the Serializable
interface.
The serialVersionUID for the class that the application hands to us must be identical to the
serialVersionUID for the class definition in Oracle database (this discussion is continued in the next
section). We set a static member variable for serialVersionUID , but if we didn't have that member, the
JVM would calculate a value. If that value is not identical, then the class cannot be realized, and the
object cannot be instantiated, and an exception will be thrown. Most often, unless we make structural
changes to the class, the calculated serialVersionUID will be identical, but that statistic of “most often”
poses a risk that we are unwilling to take.
Note that the values we provide for innerClassRevLvl and serialVersionUID are pretty much
whatever we want; however, I think a form of the date with flexibility for multiple values for any one date
will make a good value. If I release a new application on February 14, 2012, I might give these values: