Database Reference
In-Depth Information
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: