Database Reference
In-Depth Information
into Oracle database to serve as a stub on which to realize classes and objects of this type in Oracle
database.
Take a moment to compare the original inner class,
in situ
with the stub for our second application,
testojs/TestOracleJavaSecure.
Note
Compare the files named
Chapter10/ testojs/TestOracleJavaSecure.java
(the original) and
TestOracleJavaSecure.sql
(the stub).
Looking at certain aspects of our stub, I'd like to point out what's required. First in Listing 10-55,
notice the package name,
testojs
. We are going to require that application inner classes exist in a
package, in order to assure that applications may even name their inner classes the same, but have
unique names based on the package prefix. Second notice the outer, containing class definition for
TestOracleJavaSecure
. This outer class definition needs to match exactly what we see in the original
code. The inner class is named
AnyNameWeWant
.
Listing 10-55.
Stub Class for Second Test Application
CREATE OR REPLACE AND RESOLVE JAVA SOURCE NAMED appsec."testojs/TestOracleJavaSecure" AS
package testojs
;
import java.io.Serializable;
import orajavsec.RevLvlClassIntfc;
public class TestOracleJavaSecure {
public static class
AnyNameWeWant
implements Serializable, RevLvlClassIntfc
{
private static final long serialVersionUID = 2011013100L;
private String innerClassRevLvl = "20110131a";
public String getRevLvl() {
return innerClassRevLvl;
}
}
}
The definition of the inner class itself should be exactly the same as in the original code, with the
exception of the
innerClassRevLvl
string (whether you've defined it in the class or in the
getRevLvl()
method). Note that in all cases, the
public
and
private
modifiers should be maintained. We want the
inner class to be declared as
static
so that we are dealing with a single object rather than potentially
multiple instances.
In addition to being in a package, the inner class needs to be declared
public
so that the
OracleJavaSecure
class can generate the object, even though it's in a different package. The containing,
outer class should also be public for this reason.
There is a lot of flexibility in placement of the inner class within the containing class. First of all, the
containing class need not be a top level class for the application—it can be an ancillary class. In this way,
a diligent programmer may withhold sensitive code from perusal by the application security personnel
who will be generating the stub.
