1.19 Java Language Integration
Java programmers can write server-side
classes that invoke SQL and PL/SQL using standard
JDBC 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.
|