12.3 Resolution of Schema Objects

All Java classes contain references to other classes. A conventional JVM searches for classes in the directories, ZIP files, and JAR files named in the CLASSPATH. In contrast, Oracle JVM searches schemas for class schema objects. Each class in the database has a resolver specification, which is Oracle Database counterpart to CLASSPATH. For example, the resolver specification of a class, alpha, lists the schemas to search for classes that alpha uses. Notice that resolver specifications are per-class, whereas in a classic JVM, CLASSPATH is global to all classes.

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

• The name of the class schema object to call when the class uses the reference

• A code indicating whether the reference is unsatisfied, that is, whether the referent schema object is known

Oracle Database facility known as resolver maintains reference lists. For each interclass reference in a class, the resolver searches the schemas specified by the resolver specification of the class for a valid 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 depends on a schema object that becomes invalid is also marked invalid at the time the first class is marked invalid. In other words, invalidation cascades upward from a class to the classes that use it and the classes that use these classes, and so on. When resolving a class that depends on an invalid class, the resolver first tries to resolve the referenced class, because it may be marked invalid only because it has never been resolved. The resolver does not resolve classes that are marked valid.

A developer can direct the loadjava tool to resolve classes or can defer resolution until run time. The resolver runs automatically when a class tries to load a class that is marked invalid. It is best to resolve before run time to learn of missing classes early. Unsuccessful resolution at run time produces a ClassNotFound exception. Furthermore, run-time resolution can fail for the following reasons:

• Lack of database resources, if the tree of classes is very large

• Deadlocks due to circular dependencies

The loadjava tool has two resolution modes:

• Load-and-resolve

  The -resolve option loads all classes you specify on the command line, marks them invalid, and then resolves them. Use this mode when initially loading classes that refer to each other, and, in general, when reloading isolated classes as well. By loading all classes and then resolving them, this mode avoids the error message that occurs if a class refers to a class that will be loaded later while the command is being carried out.

• Load-then-resolve

  This mode resolves each class at run time. The -resolve option is not specified.

  Note:

  As with a Java compiler, the loadjava tool resolves references to classes but not to resources. Ensure that you correctly load the resource files that your classes need.

If you can, defer resolution until all classes have been loaded. This avoids a situation in which the resolver marks a class invalid because a class it uses has not yet been loaded.