1. Home
  2. SQL
  3. Oracle PL SQL Language Pocket Reference

1.19 Java Language Integration

Javafigs/U2122.gif programmers can write server-side classes that invoke SQL and PL/SQL using standard JDBCfigs/U2122.gif or SQLJ calls. PL/SQL programmers can call server-side Java methods by writing a PL/SQL cover or call spec for Java using Oracle DDL.

Server-side Java in Oracle may be faster than PL/SQL for compute-intensive programs, but not as nimble for database access. PL/SQL is much more efficient for database-intensive routines because, unlike Java, it doesn't have to pay the overhead for converting SQL datatypes for use inside the stored program. Oracle programmers will want to continue to use PL/SQL for programs that perform a lot of database I/O, and use Java for the best raw computation performance.

The first step in creating a Java stored procedure (JSP) is writing or otherwise obtaining functional Java code. Having source code is not necessary, though, so you can use class libraries from third parties. The classes must, however, meet the following requirements:

  • Methods published to SQL and PL/SQL must be declared static. PL/SQL has no mechanism for instantiating non-static Java classes.

  • The classes must not issue any GUI calls (for example, to AWT) at runtime.

If you write your own JSP, and it needs to connect to the database for access to tables or stored procedures, use standard JDBC and/or SQLJ calls in your code. Many JDBC and SQLJ reference materials are available to provide assistance in calling SQL or PL/SQL from Java, but be sure to review the Oracle-specific documentation that ships with your release.

Once you have the Java class in hand, either in source or .class file format, the next step is loading it into the database. Oracle's loadjava command-line utility is a convenient way to accomplish the load. Refer to Oracle's documentation for further assistance with loadjava.

The third step is to create a call spec for the Java method, specifying the AS LANGUAGE JAVA clause of the CREATE command. You may create a function or procedure cover as appropriate.

Finally, you may grant EXECUTE privileges on the new JSP using GRANT EXECUTE, and PL/SQL routines can now call the JSP as if it were another PL/SQL module.

1.19.1 Example

Let's write a simple "Hello, World" JSP that will accept an argument: 

package oreilly.plsquick.demos;

public class Hello {
   public static String sayIt (String toWhom) {
      return "Hello, " + toWhom + "!";
   }
}

Saved in a file called Hello.java, the source code can be loaded directly into Oracle. Doing so will automatically compile the code. Here is a simple form of the loadjava command: 

loadjava -user scott/tiger -oci8 oreilly/plsquick/
   demos/Hello.java

The Hello.java file follows the Java file placement convention for packages and thus exists in a subdirectory named oreilly/plsquick/demos.

We can fire up our favorite SQL interpreter, connect as SCOTT/TIGER, and create the call spec for the Hello.sayIt( ) method: 

CREATE FUNCTION hello_there (to_whom IN VARCHAR2)
   RETURN VARCHAR2
   AS LANGUAGE JAVA
   NAME 'oreilly.plsquick.demos.Hello.sayIt
     (java.lang.String) return java.lang.String';
/

Now we can call our function very easily:

BEGIN
   DBMS_OUTPUT.PUT_LINE(hello_there('world'));
END;
/

And we get the following as the expected output:

Hello, world!

1.19.2 Publishing Java to PL/SQL

To write a call spec, use the AS LANGUAGE JAVA clause in a CREATE statement. The syntax for this clause is: 

{ IS | AS } LANGUAGE JAVA
   NAME 'method_fullname [ (type_fullname,... ] 
      [ RETURN type_fullname ]'

method_fullname is the package-qualified name of the Java class and method. It is case-sensitive and uses dots to separate parts of the package full name. type_fullname is the package-qualified name of the Java datatype. Notice that a simple string, not a SQL name, follows the NAME keyword.

Type mapping follows most JDBC rules regarding the legal mapping of SQL types to Java types. Oracle extensions exist for Oracle-specific datatypes.

Most datatype mappings are relatively straightforward, but passing Oracle objects of a user-defined type is harder than one would think. Oracle provides a JPublisher tool that generates the Java required to encapsulate an Oracle object and its corresponding REF. Refer to Oracle's JPublisher documentation for guidelines on usage.

The AS LANGUAGE JAVA clause is the same regardless of whether you are using Java as a standalone JSP, the implementation of a packaged program, or the body of an object type method. For example, here is the complete syntax for creating JSPs as PL/SQL-callable functions or procedures: 

CREATE [OR REPLACE]
{  PROCEDURE procedure_name [(param[, param]...)]
   | FUNCTION function_name [(param[, param]...)] 
      RETURN sql_type
}
[AUTHID {DEFINER | CURRENT_USER}]
[PARALLEL_ENABLE]
[DETERMINISTIC]
{ IS | AS } LANGUAGE JAVA
   NAME 'method_fullname [ (type_fullname,... ] 
      [ RETURN type_fullname ]'

When using Java as the implementation of a packaged procedure or function, Oracle allows you to place the Java call spec in either the package specification (where the call spec substitutes for the subprogram specification) or in the package body (where the call spec substitutes for the subprogram body). Similarly, when using JSPs in object type methods, the Java call spec can substitute for either the object type method specification or its body.

Note that Java functions typically map to PL/SQL functions, but Java functions declared void map to PL/SQL procedures. Also, you will quickly learn that mistakes in mapping PL/SQL parameters to Java parameters become evident only at runtime.

1.19.3 Data Dictionary

To learn what Java library units are available in your schema, look in the USER_OBJECTS data dictionary view where the object_type is like `JAVA%'. If you see a Java class with INVALID status, it has not yet been successfully resolved. Note that the names of the Java source library units need not match the names of the classes they produce.