You can compile Java source code with a conventional Java compiler as shown in the following example:

javac <file_name>.java

After compilation, you load the compiled binary into the database, rather than the source itself. This is a better option, because it is usually easier to debug the Java code on your own system, rather than debugging it on the database.

When you specify the -resolve option with the loadjava tool for a source file, the following occurs:

Oracle Database writes all compilation errors to the log file of the loadjava tool as well as the USER_ERRORS view.

When you load the Java source into the database without the -resolve option, for example:

loadjava <file_name>.java

Then, Oracle Database compiles the source automatically when the class is needed during run time. The source file is loaded into a source schema object. Oracle Database writes all compilation errors to the log file of the loadjava tool as well as the USER_ERRORS view.

You can specify the compiler options in the following ways:

• Specify compiler options on the command line with the loadjava tool. You can also specify the encoding option with the loadjava tool.

• Specify persistent compiler options in the JAVA$OPTIONS table. The JAVA$OPTIONS table exists for each schema. Every time you compile, the compiler uses these options. However, any compiler options specified with the loadjava tool override the options defined in this table. You must create this table yourself if you wish to specify compiler options in this manner.

Oracle Database provides a dependency management and automatic build facility that transparently recompiles source programs when you make changes to the source or binary programs upon which they depend. Consider the following example:

public class A
{
  B b;
  public void assignB()
  {
    b = new B()
  }
}
public class B
{
  C c;
  public void assignC()
  {
    c = new C()
  }
}
public class C
{
  A a;
  public void assignA()
  {
    a = new A()
  }
}

The system tracks dependencies at a class level of granularity. In the preceding example, you can see that classes A, B, and C depend on one another, because A holds an instance of B, B holds an instance of C, and C holds an instance of A. If you change the definition of class A by adding a new field to it, then the dependency mechanism in Oracle Database flags classes B and C as invalid. Before you use any of these classes again, Oracle Database attempts to resolve them and recompile, if necessary. Note that classes can be recompiled only if the source file is present on the server.

The dependency system enables you to rely on Oracle Database to manage dependencies between classes, to recompile, and to resolve automatically. You must force compilation and resolution yourself only if you are developing and you want to find problems early. The loadjava tool also provides the facilities for forcing compilation and resolution if you do not want the dependency management facilities to perform this for you.

You can specify a special option within a resolver specification that allows an unresolved reference to a nonexistent class. Sometimes, internal classes are never used within a product. In a standard Java environment, this is not a problem, because as long as the methods are not called, JVM ignores them. However, when resolving a class, Oracle JVM tries to resolve all names referenced by that class, including names that may never be used. If Oracle JVM cannot find a matching class for each such names referenced by that class, then the class being resolved is marked as invalid and cannot be run.

To ignore references, you can specify the wildcard, minus sign (-), within the resolver specification. The following example specifies that any references to classes within my/gui are to be allowed, even if it is not present within the resolver specification schema list.

loadjava -resolve -resolver '((* HR) (* PUBLIC) ("my/gui/*" -))'

Without the wildcard, if a dependent class is not found within one of the schemas, your class is listed as invalid and cannot be run.

In addition, you can define that all classes not found are to be ignored. However, this is dangerous, because a class that has a dependent class will be marked as valid, even if the dependent class does not exist. However, the class can never run without the dependent class. In this case, you will receive an exception at run time.

To ignore all classes not found within HR or PUBLIC, specify the following resolver specification:

loadjava -resolve -resolver "((* HR) (* PUBLIC) (* -))"

If you later intend to load the nonexistent classes that required you to use such a resolver, then you should not use a resolver containing the minus sign (-) wildcard. Instead, include all referenced classes in the schema before resolving.

Even when a minus sign (-) wildcard is used, the super class of a class can never be nonexistent. If the super class is not found, then the class will be invalid regardless of the use of a minus sign (-) wildcard in the resolver.

According to JVM specification, .class files are subject to verification before the class they define is available in a JVM. In Oracle JVM, the verification process occurs at class resolution.

The following table describes the problems the resolver may find and the appropriate Oracle error code issued.

A resolver with the minus sign (-) wildcard marks your class valid, regardless of whether classes referenced by your class are present. Because of inheritance and interfaces, you may want to write valid Java methods that use an instance of a class as if it were an instance of a superclass or of a specific interface. When the method being verified uses a reference to class A as if it were a reference to class B, the resolver must check that A either extends or implements B. For example, consider the following potentially valid method, whose signature implies a return of an instance of B, but whose body returns an instance of A:

B myMethod(A a)
{ 
  return a; 
}

The method is valid only if A extends the class B or A implements the interface B. If A or B have been resolved using the minus sign (-) wildcard, then the resolver does not know that this method is safe. In this case, the resolver replaces the bytecodes of myMethod with bytecodes that throw an exception if myMethod is called.

A resolver without the minus sign (-) wildcard ensures that the class definitions of A and B are found and resolved properly if they are present in the schemas they specifically identify. The only time you may consider using the alternative resolver is if you must load an existing JAR file containing classes that reference other nonsystem classes, which are not included in the JAR file.

You cannot have two class objects with the same name in the same schema. This rule affects you in two ways:

• You can load either a particular Java .class file or its .java file, but not both.

  Oracle Database tracks whether you loaded a class file or a source file. If you want to update the class, then you must load the same type of file that you originally loaded. If you want to update the other type, then you must drop the first before loading the second. For example, if you loaded x.java as the source for class y, then to load x.class, you must first drop x.java.

• You cannot define the same class within two different schema objects in the same schema. For example, suppose x.java defines class y and you want to move the definition of y to z.java. If x.java has already been loaded, then the loadjava tool rejects any attempt to load z.java, which also defines y. Instead, do either of the following:

  • Drop x.java, load z.java, which defines y, and then load the new x.java, which does not define y.

  • Load the new x.java, which does not define y, and then load z.java, which defines y.

You must have the following SQL database privileges to load classes:

• CREATE PROCEDURE and CREATE TABLE privileges to load into your schema.

• CREATE ANY PROCEDURE and CREATE ANY TABLE privileges to load into another schema.

• oracle.aurora.security.JServerPermission.loadLibraryInClass. classname.

The loadjava tool accepts .class, .java, .properties, .sqlj, .ser, .jar, or .zip files. The JAR or ZIP files can contain source, class, and data files. When you pass a JAR or ZIP file to the loadjava tool, it opens the archive and loads the members of the archive individually. There is no JAR or ZIP schema object. If the JAR or ZIP content has not changed since the last time it was loaded, then it is not reloaded. Therefore, there is little performance penalty for loading JAR or ZIP files. In fact, loading JAR or ZIP files is the simplest way to use the loadjava tool.

Starting with 11g release 1 (11.1), when you load the contents of a JAR into the database, you have the option of creating a database object representing the JAR itself. In this way, you can retain an association between this JAR object and the class, resource, and source objects loaded from the JAR. This enables you to:

• Use signed JARs and JAR namespace segregation in the same way as you use them in standard JVM.

• Manage the classes that you have derived from a JAR while loading it into the database as a single unit. This helps you to prevent individual redefinition of the classes loaded from the JAR. It also enables you to drop the whole set of classes loaded from the JAR, irrespective of the contents or the continued existence of the JAR on the external file system, at the time of dropping it.

In order to load a JAR into the database, you have the following options of the loadjava tool:

• -jarsasdbobjects

• -prependjarnames