4 Generated Classes and Interfaces

Passing Output Parameters in Arrays

One way to solve the problem of returning output values in Java is to pass an OUT or IN OUT parameter to the wrapper method in a single-element array. Think of the array as a container that holds the parameter. This mechanism works as follows:

1. You assign the before value of the parameter to element [0] of an array.

2. You pass the array to your wrapper method.

3. The wrapper method assigns the after value of the parameter to element [0] of the array.

4. After running the method, you extract the after value from the array.

A setting of -outarguments=array, which is the default, instructs JPublisher to use this single-element array mechanism to publish any OUT or IN OUT argument.

For example:

Person [] pa = {p}; 
x.f(pa); 
p = pa[0]; 

Assume that x is an instance of a JPublisher-generated class that has the f() method, which is a wrapper method for a stored procedure that uses a SQL PERSON object as an IN OUT parameter. The PERSON type maps to the Person Java class. p is a Person instance, and pa[] is a single-element Person array.

This mechanism for passing OUT or IN OUT parameters requires you to add a few extra lines of code to your program for each parameter. As another example, consider the PL/SQL function created by the following SQL*Plus command:

SQL> CREATE OR REPLACE FUNCTION g (
            a0 NUMBER, 
            a1 OUT NUMBER, 
            a2 IN OUT NUMBER,
            a3 CLOB, 
            a4 OUT CLOB, 
            a5 IN OUT CLOB) 
     RETURN CLOB IS 
     BEGIN
            RETURN NULL;
     END;

With -outarguments=array, this is published as follows:

public oracle.sql.CLOB g (
     java.math.BigDecimal a0,
     java.math.BigDecimal a1[],
     java.math.BigDecimal a2[],
     oracle.sql.CLOB a3,
     oracle.sql.CLOB a4[],
     oracle.sql.CLOB a5[])

Problems similar to those described earlier arise when the this object of an instance method is modified.

The this object is an additional parameter, which is passed in a different way. Its mode, as declared in the CREATE TYPE statement, may be IN or IN OUT. If you do not explicitly declare the mode of the this object, then its mode is IN OUT, if the stored procedure does not return a result, or IN, if it does.

If the mode of the this object is IN OUT, then the wrapper method must return the new value of this. The code generated by JPublisher implements this functionality in different ways, depending on the situation, as follows:

• For a stored procedure that does not return a result, the new value of this is returned as the result of the wrapper method.

  As an example, assume that the SQL object type MYTYPE has the following member procedure:

  MEMBER PROCEDURE f1(y IN OUT INTEGER);
  
  

  Also, assume that JPublisher generates a corresponding Java class, MyJavaType. This class defines the following method:

  MyJavaType f1(int[] y)
  
  

  The f1() method returns the modified this object value as a MyJavaType instance.

• For a stored function, which is a stored procedure that returns a result, the wrapper method returns the result of the stored function as its result. The new value of this is returned in a single-element array, passed as an extra argument, which is the last argument, to the wrapper method.

  Assume that the SQL object type MYTYPE has the following member function:

  MEMBER FUNCTION f2(x IN INTEGER) RETURNS VARCHAR2;
  
  

  Then the corresponding Java class, MyJavaType, defines the following method:

  String f2(int x, MyJavaType[] newValue)
  
  

  The f2() method returns the VARCHAR2 value as a Java string and the modified this object value as an array element in the MyJavaType array.

Passing Output Parameters in JAX-RPC Holders

The JAX-RPC specification explicitly specifies holder classes in the javax.xml.rpc.holders package for the Java mapping of simple XML data types and other types. Typically, Holder is appended to the type name for the holder class name. For example, BigDecimalHolder is the holder class for BigDecimal.

Given a setting of -outarguments=holder, JPublisher uses holder instances to publish OUT and IN OUT arguments from stored procedures. Holder settings are specified in a JPublisher style file. The settings are specified in the HOLDER subtag inside the TARGETTYPE section for appropriate mapping. If no holder class is specified, then JPublisher chooses one according to defaults.

For general information about JAX-RPC and holders, refer to the Java API for XML-based RPC, JAX-RPC 1.0 specification, available at:

http://jcp.org/aboutJava/communityprocess/final/jsr101/index.html

As an example, consider the PL/SQL function created by the following SQL*Plus command:

SQL> CREATE OR REPLACE FUNCTION g (
            a0 NUMBER, 
            a1 OUT NUMBER, 
            a2 IN OUT NUMBER,
            a3 CLOB, 
            a4 OUT CLOB, 
            a5 IN OUT CLOB) 
     RETURN CLOB IS 
     BEGIN
            RETURN NULL;
     END;

Assume that the webservices10 style file contains an entry for -outarguments=holder and the following JPublisher command is used to publish the function, g():

% jpub -u scott/tiger  -s toplevel"(g)":ToplevelG -style=webservices10

The published interface is:

public java.lang.String g
              (java.math.BigDecimal a0,
               javax.xml.rpc.holders.BigDecimalHolder _xa1_out_x,
               javax.xml.rpc.holders.BigDecimalHolder _xa2_inout_x,
               java.lang.String a3,
               javax.xml.rpc.holders.StringHolder _xa4_out_x,
               javax.xml.rpc.holders.StringHolder _xa5_inout_x)
throws java.rmi.RemoteException;

In this case, there is an extra level of abstraction. Because oracle.sql.CLOB is not supported by Web services, it is mapped to String, the JAX-RPC holder class for which is StringHolder.

Passing Output Parameters in Function Returns

You can use the -outarguments=return setting as a workaround for supporting method signatures in Web services that do not use JAX-RPC holder types or arrays. If there is no support for JAX-RPC holders, the -outarguments=return setting allows OUT or IN OUT data to be returned in function results.

Consider the PL/SQL function created by the following SQL*Plus command:

SQL> CREATE OR REPLACE FUNCTION g (
            a0 NUMBER, 
            a1 OUT NUMBER, 
            a2 IN OUT NUMBER,
            a3 CLOB, 
            a4 OUT CLOB, 
            a5 IN OUT CLOB) 
     RETURN CLOB IS 
     BEGIN
            RETURN NULL;
     END;

Assume the following JPublisher command to publish the function, g(). Although the webservices10 style file specifies -outarguments=holder, the -outarguments=return setting comes after the -style setting and, therefore, takes precedence.

% jpub -u scott/tiger  -s toplevel"(g)":ToplevelG -style=webservices10
       -outarguments=return

The JPublisher output is as follows:

SCOTT.top_level_scope
ToplevelGUser_g_Out

The JPublisher output acknowledges that it is processing the SCOTT top level and also indicates the creation of the ToplevelGUser_g_Out Java class to support output values of the g() function through return data.

JPublisher generates the following interface to take input parameters and return output parameters:

public ToplevelGUser_g_Out g
            (java.math.BigDecimal a0,
             java.math.BigDecimal xxa2_inoutxx,
             java.lang.String a3,
             java.lang.String xxa5_inoutxx)
throws java.rmi.RemoteException;

JPublisher generates the TopLevelGUser_g_Out class as follows:

public class ToplevelGUser_g_Out{
  public ToplevelGUser_g_Out() { }
  public java.math.BigDecimal getA1Out()  { return a1_out; }
  public void setA1Out(java.math.BigDecimal a1_out) { this.a1_out = a1_out; }
  public java.math.BigDecimal getA2Inout()   { return a2_inout; }
  public void setA2Inout(java.math.BigDecimal a2_inout) 
                          { this.a2_inout = a2_inout; }
  public java.lang.String getA4Out()   { return a4_out; }}

The ToplevelGUser_g_Out return type encapsulates the values of the OUT and IN OUT parameters to be passed back to the caller of the function. As in the preceding section, oracle.sql.CLOB is mapped to String by the webservices10 style file.

Important Notes About Generation of SQLJ Classes

Note the following for JPublisher-generated SQLJ classes:

• If you are generating Java wrapper classes for a SQL type hierarchy and any of the types contains stored procedures, then by default, JPublisher generates SQLJ classes for all the SQL types and not just the types that have stored procedures.

  Note:

  You have the option of explicitly suppressing the generation of SQLJ classes through the JPublisher -methods=false setting. This results in all non-SQLJ classes.

• Classes produced by JPublisher include a release() method. If an instance of a JPublisher-generated wrapper class implicitly constructs a DefaultContext instance, then you should use the release() method to release this connection context instance when it is no longer needed. However, you can avoid this scenario by adhering to at least one of the following suggestions in creating and using the wrapper class instance:

  • Construct the wrapper class instance with an explicitly provided SQLJ connection context.

  • Associate the wrapper class instance explicitly with a SQLJ connection context instance through the setConnectionContext() method.

  • Use the static SQLJ default connection context instance implicitly for the wrapper class instance. This occurs if you do not supply any connection information.

  See Also:

  "Connection Contexts and Instances in SQLJ Classes"

• In the Oracle8i compatibility mode, instead of the constructor taking a DefaultContext instance or an instance of a user-specified class, there is a constructor that simply takes a ConnectionContext instance. This could be an instance of any class that implements the standard sqlj.runtime.ConnectionContext interface, including the DefaultContext class.

Use of SQLJ Classes for PL/SQL Packages

Take the following steps to use a class that JPublisher generates for a PL/SQL package:

1. Construct an instance of the class.

2. Call the wrapper methods of the class.

The constructors for the class associate a database connection with an instance of the class. One constructor takes a SQLJ DefaultContext instance or an instance of a class specified through the -context option when you run JPublisher. Another constructor takes a JDBC Connection instance. One constructor has no arguments. Calling the no-argument constructor is equivalent to passing the SQLJ default context to the constructor that takes a DefaultContext instance. JPublisher provides the constructor that takes a Connection instance for the convenience of JDBC programmers unfamiliar with SQLJ concepts, such as connection contexts and the default context.

The wrapper methods are all instance methods, because the connection context in the this object is used in the wrapper methods.

Because a class generated for a PL/SQL package has no instance data other than the connection context, you typically construct one class instance for each connection context that you use. If the default context is the only one you use, then you can call the no-argument constructor once.

An instance of a class generated for a PL/SQL package does not contain copies of the PL/SQL package variables. It is not an ORAData class or a SQLData class, and you cannot use it as a host variable.

Use of SQLJ Classes for Object Types

To use an instance of a Java class that JPublisher generates for a SQL object type or a SQL OPAQUE type, you must first initialize the Java object. You can accomplish this in one of the following ways:

• Assign an already initialized Java object to your Java object.

• Retrieve a copy of a SQL object into your Java object. You can do this by using the SQL object as an OUT argument or as the function return of a JPublisher-generated wrapper method. You can also do this by retrieving the SQL object through JDBC calls that you write. If you are in a backward-compatibility mode and use SQLJ source files directly, then you can retrieve a copy of a SQL object through the SQLJ #sql statements.

• Construct the Java object with the no-argument constructor and set its attributes by using the setXXX() methods, or construct the Java object with the constructor that accepts values for all the object attributes. Subsequently, you need to use the setConnection() or setConnectionContext() method to associate the object with a database connection before calling any of its wrapper methods. If you do not explicitly associate the object with a JDBC or SQLJ connection before calling a method on it, then it becomes implicitly associated with the SQLJ default context.

  Other constructors for the class associate a connection with the class instance. One constructor takes a DefaultContext instance or an instance of a class specified through the -context option when you run JPublisher, and one constructor takes a Connection instance. The constructor that takes a Connection instance is provided for the convenience of JDBC programmers unfamiliar with SQLJ concepts, such as connection contexts and the default context.

Once you have initialized your Java object, you can do the following:

• Call the accessor methods of the object.

• Call the wrapper methods of the object.

• Pass the object to other wrapper methods.

• Use the object as a host variable in JDBC calls. If you are in a backward-compatibility mode and use SQLJ source files directly, then you can use the object as a host variable in the SQLJ #sql statements.

There is a Java attribute for each attribute of the corresponding SQL object type, with the getXXX() and setXXX() accessor methods for each attribute. JPublisher does not generate fields for the attributes. For example, for an attribute called foo, there is a corresponding Java attribute called foo and the accessor methods, getFoo() and setFoo().

By default, the class includes wrapper methods that call the associated Oracle object methods, which reside and run on the server. Irrespective of what the server methods are, the wrapper methods are all instance methods. The DefaultContext in the this object is used in the wrapper methods.

With Oracle mapping, JPublisher generates the following methods for the Oracle JDBC driver to use:

• create()

• toDatum()

These methods are specified in the ORAData and ORADataFactory interfaces and are generally not intended for your direct use. In addition, JPublisher generates the setFrom(otherObject), setValueFrom(otherObject), and setContextFrom(otherObject) methods that you can use to copy values or connection information from one object instance to another.

Connection Contexts and Instances in SQLJ Classes

The class that JPublisher uses in creating SQLJ connection context instances depends on how you set the -context option when you run JPublisher. The following classes can be used:

• A setting of -context=DefaultContext, which is the default setting, results in JPublisher using instances of the standard sqlj.runtime.ref.DefaultContext class.

• A setting of a user-defined class that is in CLASSPATH and implements the standard sqlj.runtime.ConnectionContext interface results in JPublisher using instances of that class.

• A setting of -context=generated results in the declaration of the static _Ctx connection context class in the JPublisher-generated class. JPublisher uses instances of this class for connection context instances. This is appropriate for the Oracle8i compatibility mode, but generally not recommended.

Consider the following points in using SQLJ connection context instances or JDBC connection instances in instances of JPublisher-generated wrapper classes:

• Wrapper classes generated by JPublisher provide a setConnectionContext() method that you can use to explicitly specify a SQLJ connection context instance. The method is defined as follows:

  void setConnectionContext(conn_ctxt_instance);
  
  

  This installs the passed connection context instance as the SQLJ connection context in the wrapper class instance. The connection context instance must be an instance of the class specified through the -context setting for JPublisher connection contexts, typically DefaultContext.

  Note that the underlying JDBC connection must be compatible with the connection used to materialize the database object in the first place. Specifically, some objects may have attributes that are valid only for a particular connection, such as object reference types or BLOBs.

  If you have already specified a connection context instance through the constructor, then you need not set it again using the setConnectionContext() method.

• Use either of the following methods of a wrapper class instance, as appropriate, to retrieve a connection or connection context instance:

  • Connection getConnection()

  • ConnCtxtType getConnectionContext()

  The getConnectionContext() method returns an instance of the connection context class specified through the JPublisher -context setting, typically DefaultContext.

  The returned connection context instance may be either an explicitly set instance or one that was created implicitly by JPublisher.

• If no connection context instance is explicitly set for a JPublisher-generated SQLJ class, then one will be created implicitly from the JDBC connection instance when the getConnectionContext() method is called.

  In this circumstance, at the end of processing, you need to use the release() method to free resources in the SQLJ run time. This prevents a possible memory leak.

The setFrom(), setValueFrom(), and setContextFrom() Methods

JPublisher provides the following utility methods in the generated SQLJ classes:

• setFrom(anotherObject)

  This method initializes the calling object from another object of the same base type, including connection and connection context information. An existing, implicitly created connection context object on the calling object is freed.

• setValueFrom(anotherObject)

  This method initializes the underlying field values of the calling object from another object of the same base type. This method does not transfer connection or connection context information.

• setContextFrom(anotherObject)

  This method initializes the connection and connection context information on the calling object from the connection setting of another object of the same base type. An existing, implicitly created, connection context object on the calling object is freed. This method does not transfer any information related to the object value.

Note that there is semantic equivalence between the setFrom() method and the combination of the setValueFrom() and setContextFrom() methods.

Extending JPublisher-Generated Classes

Suppose you want JPublisher to generate the JAddress class from the ADDRESS SQL object type. You also want to write a class, MyAddress, to represent ADDRESS objects, where MyAddress extends the functionality that JAddress provides.

Under this scenario, you can use JPublisher to generate both a base Java class, JAddress, and an initial version of a subclass, MyAddress, to which you can add the desired functionality. You then use JPublisher to map ADDRESS objects to the MyAddress class instead of the JAddress class.

To do this, JPublisher alters the code it generates in the following ways:

• It generates the MyAddressRef reference class instead of JAddressRef.

• It uses the MyAddress class, instead of the JAddress class, to represent attributes with the SQL type ADDRESS or to represent VARRAY and nested table elements with the SQL type ADDRESS.

• It uses the MyAddress factory, instead of the JAddress factory, when the ORADataFactory interface is used to construct Java objects with the SQL type ADDRESS.

• It generates or regenerates the code for the JAddress class. In addition, it generates an initial version of the code for the MyAddress class, which you can then modify to insert your own additional functionality. However, if the source file for the MyAddress class already exists, then it is left untouched by JPublisher.

-sql=object_type:generated_base_class:map_class

-sql=ADDRESS:JAddress:MyAddress

SQL ADDRESS GENERATE JAddress AS MyAddress

JPublisher-Generated Subclasses for Java-to-Java Type Transformations

JPublisher style files enable you to specify Java-to-Java type mappings. A typical use for such mappings is to ensure that generated classes can be used in Web services. As a particular example, CLOB types, such as java.sql.Clob and oracle.sql.CLOB, cannot be used in Web services. However, the data can be used if converted to a type that is supported by Web services, such as java.lang.String.

If you use the JPublisher -style option to specify a style file, then JPublisher generates subclasses that implement the Java-to-Java type mappings specified in the style file. This includes the use of holder classes for handling output arguments and data corresponding to PL/SQL OUT or IN OUT types.

For example, consider the following PL/SQL package, foo_pack, consisting of the stored function, foo:

CREATE OR REPLACE PACKAGE foo_pack AS 
   FUNCTION foo(a IN OUT SYS.XMLTYPE, b INTEGER) RETURN CLOB; 
END; 
/

Assume that you translate the foo_pack package as follows:

% jpub -u scott/tiger -s foo_pack:FooPack -style=webservices10

This command uses the style file webservices10.properties for Java-to-Java type mappings. Among other things, the webservices10.properties file specifies the following:

• The mapping of the oracle.sql.SimpleXMLType Java type, which is not supported by Web services, to the javax.xml.transform.Source Java type. This is specified in the style file as follows:

  SOURCETYPE oracle.sql.SimpleXMLType
  TARGETTYPE javax.xml.transform.Source
  ...
  
  

• The use of holder classes for PL/SQL OUT and IN OUT arguments:

  jpub.outarguments=holder
  
  

  This setting directs JPublisher to use instances of the appropriate holder class, in this case javax.xml.rpc.holders.SourceHolder, for the PL/SQL output argument of the XMLTYPE type.

• The inclusion of webservices-common.properties:

  INCLUDE webservices-common
  
  

The webservices-common.properties file, which is also supplied by Oracle, specifies the following:

• The mapping of SYS.XMLTYPE to oracle.sql.SimpleXMLType in the JPublisher default type map:

  jpub.adddefaulttypemap=SYS.XMLTYPE:oracle.sql.SimpleXMLType
  
  

• A code generation naming pattern:

  jpub.genpattern=%2Base:%2User#%2
  
  

  Based on the -s foo_pack:FooPack specification to JPublisher, the genpattern setting results in the generation of the FooPack interface, the base class FooPackBase, and the user subclass FooPackUser, which extends FooPackBase and implements FooPack.

  See Also:

  "Class and Interface Naming Pattern"

• The mapping of the oracle.sql.CLOB Java type, which is not supported by Web services, to the java.lang.String Java type:

  SOURCETYPE oracle.sql.CLOB
  TARGETTYPE java.lang.String
  ...
  
  

Recall the calling sequence for the stored function foo:

FUNCTION foo(a IN OUT SYS.XMLTYPE, b INTEGER) RETURN CLOB;

The base class generated by JPublisher, FooPackBase, has the following corresponding method declaration:

public oracle.sql.CLOB _foo (oracle.sql.SimpleXMLType a[], Integer b)

The base class uses an array to hold the output argument.

The user subclass has the following corresponding method declaration:

public java.lang.String foo (SourceHolder _xa_inout_x, Integer b)

This declaration is because of the specified mapping of oracle.sql.SimpleXMLType to javax.xml.transform.Source, the specified use of holder classes for output arguments, and the specified mapping of oracle.sql.CLOB to java.lang.String.

The following is the code for the SourceHolder class, which is the holder class for javax.xml.transform.Source:

// Holder class for javax.xml.transform.Source
public class SourceHolder implements javax.xml.rpc.holders.Holder
{
   public javax.xml.transform.Source value;
   public SourceHolder() { }
   public SourceHolder(javax.xml.transform.Source value)
   { this.value = value; }
}

Generated user subclasses employ the following general functionality for Java-to-Java type transformations in the wrapper method:

User subclass method
{
     Enter Holder layer (extract IN data from the holder)
          Enter Java-to-Java mapping layer (from target to source)
               Call base class method (uses JDBC to invoke wrapped procedure)
          Exit Java-to-Java mapping layer (from source to target)
     Exit Holder layer (update the holder)
}

For this example, the foo() method of the FooPackUser class is defined as follows:

foo (SourceHolder, Integer)
{
     SourceHolder -> Source
          Source -> SimpleXMLType
               _foo (SimpleXMLType[], Integer);
          SimpleXMLType -> Source
     Source -> SourceHolder
}

The holder layer retrieves and assigns the holder instance.

In the example, the holder layer in foo() performs the following:

1. It retrieves a Source object from the SourceHolder object that is passed in to the foo() method.

2. After processing, which occurs inside the type conversion layer, it assigns the SourceHolder object from the Source object that was retrieved and processed.

The type conversion layer first takes the target type, TARGETTYPE from the style file, and converts it to the source type, SOURCETYPE from the style file. It then calls the corresponding method in the base class, which uses JDBC to invoke the wrapped stored function. Finally, it converts the source type returned by the base class method back into the target type to return to the holder layer.

In this example, the type conversion layer in foo() performs the following:

1. It takes the Source object from the holder layer.

2. It converts the Source object to a SimpleXMLType object.

3. It passes the SimpleXMLType object to the _foo() method of the base class, which uses JDBC to invoke the foo stored function.

4. It takes the SimpleXMLType object returned by the _foo() method.

5. It converts the SimpleXMLType object back to a Source object for the holder layer.

ORAData Object Types and Inheritance

Consider the following SQL object types:

CREATE TYPE PERSON AS OBJECT (
...
) NOT FINAL;

CREATE TYPE STUDENT UNDER PERSON (
...
);

CREATE TYPE INSTRUCTOR UNDER PERSON (
...
);

Consider the following JPublisher command to create corresponding Java classes:

% jpub -user=scott/tiger
       -sql=PERSON:Person,STUDENT:Student,INSTRUCTOR:Instructor -usertypes=oracle

In this example, JPublisher generates a Person class, a Student class, and an Instructor class. The Student and Instructor classes extend the Person class, because STUDENT and INSTRUCTOR are subtypes of PERSON.

The class at the root of the inheritance hierarchy, Person in this example, contains full information for the entire inheritance hierarchy and automatically initializes its type map with the required information. As long as you use JPublisher to generate all the required classes of a class hierarchy together, no additional action is required. The type map of the class hierarchy is appropriately populated.

This section covers the following topics:

• Precautions when Combining Partially Generated Type Hierarchies

• Mapping of Type Hierarchies in JPublisher-Generated Code

% jpub -user=scott/tiger -sql=PERSON:Person,STUDENT:Student -usertypes=oracle
% jpub -user=scott/tiger -sql=PERSON:Person,INSTRUCTOR:Instructor
       -usertypes=oracle

new Instructor(); // required
new Student();    // required
new Person();     // optional

Person create(oracle.sql.Datum d, int sqlType)

ORAData Reference Types and Inheritance

This section shows how to convert from one custom reference class to another and also explains why a custom reference class generated by JPublisher for a subtype does not extend the reference classes of the base type.

This section covers the following topics:

• Casting a Reference Type Instance into Another Reference Type

• Why Reference Type Inheritance Does Not Follow Object Type Inheritance

• Manually Converting Between Reference Types

• Example: Manually Converting Between Reference Types

StudentRef s_ref = ...;  
PersonRef p_ref = PersonRef.cast(s_ref);

PersonRef pr = ...; 
InstructorRef ir = InstructorRef.cast(pr);

CREATE TYPE PERSON AS OBJECT (
...
) NOT FINAL;

CREATE TYPE STUDENT UNDER PERSON (
...
);

% jpub -user=scott/tiger -sql=PERSON:Person,STUDENT:Student -usertypes=oracle

java.sql.Connection conn = ...;  // get underlying JDBC connection
XxxxRef xref = ...;
YyyyRef yref = (YyyyRef) YyyyRef.getORADataFactory().
                create(xref.toDatum(conn),oracle.jdbc.OracleTypes.REF);

CREATE TYPE person_t AS OBJECT (ssn NUMBER, name VARCHAR2(30), dob DATE) NOT FINAL;
/
SHOW ERRORS

CREATE TYPE instructor_t UNDER person_t (title VARCHAR2(20)) NOT FINAL;
/
SHOW ERRORS

CREATE TYPE instructorPartTime_t UNDER instructor_t (num_hours NUMBER);
/
SHOW ERRORS

CREATE TYPE student_t UNDER person_t (deptid NUMBER, major VARCHAR2(30)) NOT FINAL;
/
SHOW ERRORS

CREATE TYPE graduate_t UNDER student_t (advisor instructor_t);
/
SHOW ERRORS

CREATE TYPE studentPartTime_t UNDER student_t (num_hours NUMBER);
/
SHOW ERRORS

CREATE TABLE person_tab OF person_t;

INSERT INTO person_tab VALUES (1001, 'Larry', TO_DATE('11-SEP-60'));

INSERT INTO person_tab VALUES (instructor_t(1101, 'Smith', TO_DATE('09-OCT-1940'), 'Professor'));

INSERT INTO person_tab VALUES (instructorPartTime_t(1111, 'Myers', TO_DATE('10-OCT-65'), 'Adjunct Professor', 20));

INSERT INTO person_tab VALUES (student_t(1201, 'John', To_DATE('01-OCT-78'), 11, 'EE'));

INSERT INTO person_tab VALUES (graduate_t(1211, 'Lisa', TO_DATE('10-OCT-75'), 12, 'ICS', instructor_t(1101, 'Smith', TO_DATE ('09-OCT-40'), 'Professor')));

INSERT INTO person_tab VALUES (studentPartTime_t(1221, 'Dave', TO_DATE('11-OCT-70'), 13, 'MATH', 20));

Person_t:Person,instructor_t:Instructor,instructorPartTime_t:InstructorPartTime,
graduate_t:Graduate,studentPartTime_t:StudentPartTime

import java.sql.*; 
import oracle.jdbc.*; 
import oracle.sql.*; 

public class Inheritance 
{ 
  public static void main(String[] args) throws SQLException 
  { 
    System.out.println("Connecting."); 
    java.sql.DriverManager.registerDriver(new oracle.jdbc.OracleDriver()); 
    oracle.jdbc.OracleConnection conn = 
              (oracle.jdbc.OracleConnection) java.sql.DriverManager.getConnection
              ("jdbc:oracle:oci8:@", "scott", "tiger");
    // The following is only required in 9.0.1 
    // or if the Java class hierarchy was created piecemeal 
    System.out.println("Initializing type system."); 
    new Person(); 
    new Instructor(); 
    new InstructorPartTime(); 
    new StudentT(); 
    new StudentPartTime(); 
    new Graduate(); 
    PersonRef p_ref; 
    InstructorRef i_ref; 
    InstructorPartTimeRef ipt_ref; 
    StudentTRef s_ref; 
    StudentPartTimeRef spt_ref; 
    GraduateRef g_ref; 
    OraclePreparedStatement stmt =
                (OraclePreparedStatement)conn.prepareStatement
                ("select ref(p) FROM PERSON_TAB p WHERE p.NAME=:1"); 
    OracleResultSet rs; 

    System.out.println("Selecting a person."); 
    stmt.setString(1, "Larry"); 
    rs = (OracleResultSet) stmt.executeQuery(); 
    rs.next(); 
    p_ref = (PersonRef) rs.getORAData(1, PersonRef.getORADataFactory()); 
    rs.close(); 

    System.out.println("Selecting an instructor."); 
    stmt.setString(1, "Smith"); 
    rs = (OracleResultSet) stmt.executeQuery(); 
    rs.next(); 
    i_ref = (InstructorRef) rs.getORAData(1, InstructorRef.getORADataFactory()); 
    rs.close(); 

    System.out.println("Selecting a part time instructor."); 
    stmt.setString(1, "Myers"); 
    rs = (OracleResultSet) stmt.executeQuery(); 
    rs.next(); 
    ipt_ref = (InstructorPartTimeRef) rs.getORAData
              (1, InstructorPartTimeRef.getORADataFactory()); 
    rs.close(); 

    System.out.println("Selecting a student."); 
    stmt.setString(1, "John"); 
    rs = (OracleResultSet) stmt.executeQuery(); 
    rs.next(); 
    s_ref = (StudentTRef) rs.getORAData(1, StudentTRef.getORADataFactory()); 
    rs.close(); 

    System.out.println("Selecting a part time student."); 
    stmt.setString(1, "Dave"); 
    rs = (OracleResultSet) stmt.executeQuery(); 
    rs.next(); 
    spt_ref = (StudentPartTimeRef) rs.getORAData
              (1, StudentPartTimeRef.getORADataFactory()); 
    rs.close(); 

    System.out.println("Selecting a graduate student."); 
    stmt.setString(1, "Lisa"); 
    rs = (OracleResultSet) stmt.executeQuery(); 
    rs.next(); 
    g_ref = (GraduateRef) rs.getORAData(1, GraduateRef.getORADataFactory()); 
    rs.close(); 
    stmt.close(); 

    // Assigning a part-time instructor ref to a person ref 
    System.out.println("Assigning a part-time instructor ref to a person ref"); 
    oracle.sql.Datum ref = ipt_ref.toDatum(conn); 
    PersonRef pref = (PersonRef) PersonRef.getORADataFactory(). 
                                           create(ref,OracleTypes.REF); 
    // or just use: PersonRef pref = PersonRef.cast(ipt_ref); 
    // Assigning a person ref to an instructor ref 
    System.out.println("Assigning a person ref to an instructor ref"); 
    InstructorRef iref = (InstructorRef) InstructorRef.getORADataFactory(). 
                                     create(pref.toDatum(conn), OracleTypes.REF); 
    // or just use: InstructorRef iref = InstructorRef.cast(pref); 
    // Assigning a graduate ref to an part time instructor ref. 
    // This should produce an error, demonstrating that refs 
    // are type safe. 
    System.out.println ("Assigning a graduate ref to a part time instructor ref"); 
    InstructorPartTimeRef iptref = 
                (InstructorPartTimeRef) InstructorPartTimeRef.getORADataFactory(). 
                create(g_ref.toDatum(conn), OracleTypes.REF); 
    // or just use: InstructorPartTimeRef iptref = 
    // InstructorPartTimeRef.cast(g_ref); 
    conn.close(); 
  } 
} 

SQLData Object Types and Inheritance

If you use the JPublisher -usertypes=jdbc setting instead of -usertypes=oracle, then the custom Java class generated by JPublisher implements the standard SQLData interface instead of the Oracle ORAData interface. The standard SQLData methods, readSQL() and writeSQL(), provide functionality equivalent to the ORAData/ORADataFactory methods, create() and toDatum(), for reading and writing data.

When JPublisher generates SQLData classes corresponding to a SQL hierarchy, the Java types follow the same hierarchy as the SQL types. This is similar to the case when JPublisher generates ORAData classes corresponding to a hierarchy of SQL object types. However, SQLData implementations do not offer the implicit mapping intelligence that JPublisher automatically generates in ORAData classes.

In a SQLData scenario, you must manually provide a type map to ensure correct mapping between SQL object types and Java types. In a JDBC application, you can properly initialize the default type map for your connection or you can explicitly provide a type map as a getObject() input parameter.

In addition, note that there is no support for strongly typed object references in an SQLData implementation. All object references are weakly typed java.sql.Ref instances.

Effects of Using SQL FINAL, NOT FINAL, NOT INSTANTIABLE

This section discusses the effect of using the SQL modifiers FINAL, NOT FINAL, or NOT INSTANTIABLE on JPublisher-generated wrapper classes.

Using the SQL modifier FINAL or NOT FINAL on a SQL type or on a method of a SQL type has no effect on the generated Java wrapper code. This ensures that, in all cases, JPublisher users are able to customize generated Java wrapper classes by extending the classes and overriding the generated behavior.

Using the NOT INSTANTIABLE SQL modifier on a method of a SQL type results in no code being generated for that method in the Java wrapper class. Therefore, to call such a method, you must cast to some wrapper class that corresponds to an instantiable SQL subtype.

Using NOT INSTANTIABLE on a SQL type results in the corresponding wrapper class being generated with protected constructors. This will remind you that instances of that class can be created only through subclasses that correspond to the instantiable SQL types.