SQLJ in the Server

About Class Loading, Compiling, and Name Resolution

Class loading and name resolution in the server follow a very different paradigm than on a client, as the environments themselves are very different. This section discusses that paradigm.

SQL Names vs. Java Names

SQL names (such as names of source, class, and resource schema objects) are not global in the way that Java names are global. The Java Language Specification directs that package names use Internet naming conventions to create globally unique names for Java programs. By contrast, a fully qualified SQL name is interpreted only with respect to the current schema and database. For example, the name SCOTT.FIZZ in one database does not necessarily denote the same program as SCOTT.FIZZ in another database. In fact, SCOTT.FIZZ in one database can even call SCOTT.FIZZ in another database.

Because of this inherent difference, SQL names must be interpreted and handled differently than Java names. SQL names are relative names and are interpreted from the point of view of the schema where a program is executed. This is central to how the program binds local data stored at that schema. Java names are global names, and the classes that they designate may be loaded at any execution site, with reasonable expectation that those classes will be classes that were used to compile the program.

Java Name Resolution

Java name resolution in the Oracle8i Java VM involves the following:

class resolver specs, which are schema lists to search in resolving a class schema object (functionally equivalent to the CLASSPATH on a client)
the resolver, which maintains mappings between class schema objects and Java classes called by Java programs in the server

A class schema object is said to be resolved when all of its external references to Java names are bound. In general, all the classes of a Java program should be compiled or loaded before they can be resolved. (This is because Java programs are typically written in multiple source files that may reference each other recursively.)

When all of the class schema objects of a Java program in the server are resolved, and none of them have been modified since being resolved, the program is effectively pre-linked and ready to run.

A class schema object must be resolved before Java objects of the class can be instantiated or methods of the class can be executed.

Note:
The loadjava utility resolves references to classes but not to resources. If you translated on the client, be careful how you load any resources into resource schema objects in the server, as discussed in "Naming of Class and Resource Schema Objects". (You will typically have no resources, only classes, if you used the SQLJ -ser2class option.)

Oracle Resolver Specs

Many Java classes contain references to other classes. A conventional Java VM searches for classes in the directories, .zip files, and .jar files named in the CLASSPATH. By contrast, the Oracle8i Java VM searches schemas for class schema objects. Each class schema object has a resolver spec, which is equivalent to a CLASSPATH. The resolver spec for a hypothetical class Alpha is a list of schemas to search to find classes used by Alpha. Note that resolver specs apply to individual classes, whereas a CLASSPATH is global to all classes.

Oracle Resolver

In addition to a resolver spec, each class schema object has a list of interclass reference bindings. Each item in the reference list contains a reference to another class in addition to one of the following:

the name of the class schema object to invoke when the reference is used
a code indicating that the reference is unsatisfied; in other words, that the schema object is not known

Reference lists are maintained by an Oracle8i facility called the resolver. For each interclass reference in a class, the resolver searches the schemas specified by the class's resolver spec and looks for a class schema object that satisfies the reference. If all references are resolved, then the resolver marks the class valid. A class that has never been resolved, or has been resolved unsuccessfully, is marked invalid. A class that may use a schema object that becomes invalid is marked invalid; in other words, invalidation cascades upward from a class to the classes that use it and the classes that use them, and so on.

Resolving with loadjava

You can direct loadjava to resolve classes as you load them, or you can defer resolution to runtime. Deferring resolution is not recommended because unsuccessful resolution will likely cause problems for end users when they run your application.

The loadjava utility has the following resolution mode (in addition to "defer resolution"):

Load-then-resolve (-resolve option, or -r): Load all classes specified on the command line, mark them invalid, and then resolve them. Use this mode when initially loading classes that refer to each other. By loading all classes and then resolving them, this mode avoids the problem of marking a class invalid if it refers to a class that will be loaded later in the execution of the command.

When you use loadjava to resolve a class schema object, you can choose one of the following resolver specs:

Oracle resolver (-oracleresolver option)--definer's schema and the PUBLIC schema
JDK resolver (-jdkresolver option) (default)--definer's schema, the PUBLIC schema, and the current schema at the time the class is resolved
User-specified resolver (-resolver option)

For more information about these loadjava options, see the Oracle8i Enterprise JavaBeans and CORBA Developer's Guide.