|
Chapter 1 Oracle PL/SQL Language Pocket Reference |
In Oracle8 i , Java(TM) programmers can write server-side classes that invoke SQL and PL/SQL using standard JDBC(TM) 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 mechanisms 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 Oracle8 i .
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.
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 , we can load the source code directly into Oracle. Doing so will automatically compile the code. 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 so exists in a subdirectory named oreilly/plsquick/demos .
Now 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:
Hello, world!
as the expected output.
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 an 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 Oracle8 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 Oracle8 object and its corresponding REF. Refer to Oracle's JPublisher documentation for guidelines on usage.
The AS LANGUAGE JAVA clause is the same 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.
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.
As of press time, there is no apparent way to discover which stored programs are implemented as Java stored procedures. You can look in the USER_SOURCE view for named programs that contain the source text `AS LANGUAGE JAVA', but that may not yield accurate results. The USER_DEPENDENCIES view does not track the relationship between PL/SQL cover programs and their underlying Java class.
Even if you have loaded the Java source code into the database, there is no supported way of retrieving the source from the data dictionary.
|
|
|
|
| 1.18 External Procedures |
Copyright (c) 2000 O'Reilly & Associates. All rights reserved.