Use the "CREATE OR REPLACE JAVA SOURCE" command or "loadjava" utility.

To load java source in the database:

create or replace java source named "Hello" as

        public class Hello {                      
        /* Pure Java Code */

                static public String Msg(String tail) {

                        return "Hello " + tail;

                }

        }

To publish Java to PL/SQL:

create or replace function hello (str varchar2) return varchar as

        language java name 'Hello.Msg(java.lang.String) return java.lang.String';
/

To call Java function:

select hello('Friend') from dual
/

Loaded code can be viewed by selecting from the USER_SOURCE view.

Publishing Java classes on the database makes it visible on a SQL and PL/SQL level. It is important to publish your code before calling it from SQL statements or PL/SQL code, for example:

create or replace function hello (str varchar2) return varchar as

           language java name 'Hello.Msg(java.lang.String) return java.lang.String';

        /

A Java Stored Procedure is a procedure coded in Java (as opposed to PL/SQL) and stored in the Oracle database. Java Stored procedures are executed by the database JVM in database memory space.

Java Stored Procedures can be developed in JDBC or SQLJ. Interfacing between PL/SQL and Java are extremely easy. Please note that Java Stored procedures are by default executed with invokers rights. PL/SQL procedures are by default executed with defines rights.

Note: JSP is Java Server Pages and NOT Java Stored Procedures.

Create a deployment profile from JDeveloper or use the loadjava command line utility.

SQL*Plus: drop java class .../ drop package ... (drop the wrapper) dropjava utility: dropjava -u scott/tiger myPackage.myClass

From SQL*Plus: Use execute or call

From JDBC: Use the CallableStatement object

From SQLJ: #sql { call ...} eg: #sql { call ACME.BEGINRENTAL(:in memberID, :in employeeID, :out, ...) };

Console output from System.out.println() statements will be written to trace files in the Oracle UDUMP destination directory.

Issue the following commands in SQL*Plus before running the java stored procedure:

set serveroutput on size 100000

exec dbms_java.set_output(1000000)

One million (bytes) is the maximum size that the output buffer can be set to.

You could also check the Oracle log files in the 'background_dump_dest' directory. To find out more on that directory, issue the following command:

show parameter background_dump_dest

One can load the obfuscated, compiled java class into the database. Using database security mechanisms also limits non-authorized access to Java in the database.

Installing Oracle JVM creates the DBMS_JAVA PL/SQL package. The corresponding Java class, DbmsJava, provides methods for accessing database functionality from Java. For more details refer to the DBMS_JAVA package section in the developer's guide.

The Oracle JVM contains a number of components including the following:

compiler: Standard Java compiler. When the CREATE JAVA SOURCE statement is run, it translates Java source files into architecture-neutral, one-byte instructions known as bytecodes. interpreter: To run Java programs, Oracle JVM includes a standard Java2 bytecode interpreter. The interpreter and the associated Java run-time system run standard Java class files. The run-time system supports native methods and call-in and call-out from the host environment.

library manager: Loads java source, class and resource files into the database

class loader: During runtime finds the java class, and loads and initializes java classes for Oracle JVM

verifier: works with oracle and java security to validate java classes

server-side internal jdbc driver: java driver in the oracle database supporting java database calls

server-side SQLJ translator: translates SQLJ code into JDBC code

system classes: A set of classes that constitute a significant portion of the implementation of Java in Oracle Database environment, defined in the SYS schema and exported for all users by public synonym.

With Oracle 11g release 1 (11.1), there is a just-in-time (JIT) compiler for Oracle JVM environment. A JIT compiler for Oracle JVM enables much faster execution because; it manages the invalidation, recompilation, and storage of code without an external mechanism. It's a replacement of the compilers that were used in the earlier versions of Oracle Database.

Starting with Oracle 11g release 1 (11.1), there is a just-in-time (JIT) compiler for Oracle JVM environment. Based on dynamically gathered profiling data, this compiler transparently selects Java methods to compile the native machine code and dynamically makes them available to running Java sessions. Additionally, the compiler can take advantage of Oracle JVM's class resolution model to optionally persist compiled Java methods across database calls, sessions, or instances. Such persistence avoids the overhead of unnecessary recompilations across sessions or instances, when it is known that semantically the Java code has not changed.

The JIT compiler is controlled by a new boolean-valued initialization parameter called java_jit_enabled. When running heavily used Java methods with java_jit_enabled parameter value as true, the Java methods are automatically compiled to native code by the JIT compiler and made available for use by all sessions in the instance. For more details refer to the Oracle JVM Just-in-Time Compiler (JIT) section in the developer's guide.

a) ORA-00904 Invalid column name b) ORA-29547: Java system class not available Install the jserver component running initjvm.sql.

Invoker's rights: By default, a Java class is associated with invoker's rights; the class is not bound to its defining schema. The current user of any session executing the class is the same as the session's login user. The privileges are checked at runtime, and external references are resolved in the schema of the current user. With invoker's rights, you can centralize and share code across multiple schemas and applications while keeping data stored in each schema private and isolated.

Definer's rights: By assigning definer's rights to a class, you bind the class to its defining schema. The effective user of any session executing the class is changed temporarily to the identity of the class's defining schema, and all unqualified references are looked for in the defining schema. Java classes loaded with definer's rights can be executed without requiring the invoking session to be connected as the schema to which the code belongs.

In SQL*Plus, you can define top-level call specifications interactively, using the following syntax :

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 (java_type_fullname[, java_type_fullname]...)

[return java_type_fullname]';

where param is represented by the following syntax :

parameter_name [IN | OUT | IN OUT] sql_type

The AUTHID clause determines whether a stored procedure runs with the privileges of its definer or invoker, which is the default, and whether its unqualified references to schema objects are resolved in the schema of the definer or invoker. You can override the default behavior by specifying DEFINER.

A Java method is called from SQL or PL/SQL through a corresponding wrapper. Java wrappers are special PL/SQL entities, which expose Java methods to SQL and PL/SQL as PL/SQL stored procedures or functions. Such a wrapper might change the current effective user. The wrappers that change the current effective user to the owner of the wrapper are called definer's rights wrappers. By default, Java wrappers are definer's rights wrappers. If you want to override this, then create the wrapper using the AUTHID CURRENT_USER option. You can load a Java class to the database with the loadjava -definer option. Any method of a class having the definer attribute marked, becomes a definer's rights method.

However, you cannot override the loadjava option -definer by specifying CURRENT_USER.

Note: Prior to Oracle Database 11g release 1 (11.1), granting execute right to a stored procedure would mean granting execute right to both the stored procedure and the Java class referred by the stored procedure. In Oracle Database 11g release, if you want to grant execute right on the underlying Java class as well, then you must grant execute right on the class explicitly. This is implemented for better security.