sqlj.alter_java_path

Use sqlj.alter_java_path( ) to specify the jar-file path to use when the routine manager resolves related Java™ classes for the JAR file of a UDR written in the Java™ language.
(explicit id sajp002) sajp002

sqlj.alter_java_path

sqlj.alter_java_path
( <Jar Name>[] ( package_id. { * | class_id } , <Jar Name>[] ))
Argument Description Restrictions Syntax
class_id Java™ class that contains method to implement the UDR Java™ class must exist in the JAR file that jar_id specifies. Identifier must not exceed 255 bytes. Language specific
package_id Name of the package that contains the Java™ class The fully qualified identifier of package_id.class_id must not exceed 255 bytes Language specific

The JAR IDs that you specify, namely the JAR ID for which you are altering the JAR-file path and the resolution JAR ID, must both have been installed with the sqlj.install_jar procedure. When you invoke a UDR written in the Java™ language, the routine manager attempts to load the Java™ class in which the UDR resides. At this time, it must resolve the references that this Java™ class makes to other Java™ classes.

The three types of such class references are these:
  1. References to Java™ classes that the JVPCLASSPATH configuration parameter specifies (such as Java™ system classes like java.util.Vector)
  2. References to classes that are in the same JAR file as the UDR
  3. References to classes that are outside the JAR file that contains the UDR.

The routine manager implicitly resolves classes of type 1 and 2 in the preceding list. To resolve type 3 references, it examines all the JAR files in the JAR file path that the latest call to sqlj.alter_java_path( ) specified.

The routine manager issues an exception if it cannot resolve a class reference. The routine manager checks the JAR file path for class references after it performs the implicit type 1 and type 2 resolutions.

If you want a Java™ class to be loaded from the JAR file that the JAR file path specifies, make sure the Java™ class is not present in the JVPCLASSPATH configuration parameter. Otherwise, the system loader picks up that Java™ class first, which might result in a different class being loaded than what you expect.

Suppose that the sqlj.install_jar( ) procedure and CREATE FUNCTION have been executed as the preceding sections describe. The following SQL statement invokes sql_explosive_reaction( ) function in the course_jar JAR file: 
EXECUTE PROCEDURE alter_java_path("course_jar", 
   "(professor/*, prof_jar)");
EXECUTE FUNCTION sql_explosive_reaction(10000);

The routine manager attempts to load the class Chemistry. It uses the path that the call to sqlj.alter_java_path( ) specifies to resolve any class references. Therefore, it checks the classes that are in the professor package of the JAR file that prof_jar identifies.

If the IFX_EXTEND_ROLE configuration parameter is enabled (which is its default setting), only the DBSA or users who hold the EXTEND role are able to execute the sqlj.alter_java_path( ) procedure. When IFX_EXTEND_ROLE is disabled, any user can execute sqlj.alter_java_path( ). (But regardless of the IFX_EXTEND_ROLE setting, you must hold the Resource privilege or the DBA privilege on the database, and also hold the Usage privilege on the Java™ language, before you can create or drop a Java™ UDR.)

1 See Jar Name