1 Introduction to Java in Oracle Database

1.2.1 Upgrading to J2SE 1.4.1

In this release, the system classes are upgraded from J2SE 1.3 to J2SE 1.4.1. J2SE 1.4.1 is compatible with J2SE 1.3. Sun Microsystems publishes the list of incompatibilities between J2SE 1.4.1 and previous versions at the following Web site:

http://java.sun.com/products/j2se/1.4.1/compatibility.html

As part of the upgrade of the system classes to J2SE 1.4.1, the OracleJVM supports Headless AWT. Headless AWT allows AWT computation, which does not rely on the native display and input devices of the platform to occur, but, instead, disallows attempts to access those native resources. Methods that attempt to display a graphical user interface or to read from keyboard or mouse input instead throw the new runtime exception java.awt.HeadlessException. Similarly, the OracleJVM disallows attempts to play or record sound using the server's native sound devices, but still allows applications to read, write and manipulate supported sound files. For more information, see "User Interfaces on the Server".

1.2.2 New Memory Model for Dedicated Mode Sessions

In Oracle Database, the OracleJVM has a new memory model for sessions that connect to the database through a dedicated server. Since a session using a dedicated server is guaranteed to use the same process for every database call, the Process Global Area is used for session specific memory and object allocations. This means that some of the objects and resources that used to be reclaimed at the end of each call can now live across calls. In particular, resources specific to a particular operating system, such as threads and open files, now are no longer cleaned up at the end of each database call.

For sessions that use shared servers, the restrictions across calls that applied in previous releases are still present. The reason is that a session that uses a shared server is not guaranteed to connect to the same process on a subsequent database call, and hence the session-specific memory and objects that need to live across calls are saved in the System Global Area. This means that process-specific resources, such as threads, open files and sockets must be cleaned up at the end of each call, and hence will not be available for the next call. For more details on OracleJVM behavior when using shared servers, see "Special Considerations for Shared Servers".

1.2.3 Database Web Services Callouts

In Oracle Database, you can load a Web Services client stack into the OracleJVM to support callouts to external Web Services from Java as well as from PL/SQL. You can use the JPublisher tool to generate static Java client-proxies as well as PL/SQL call specifications on these proxies that are loaded into the OracleJVM to enable access to Web Services from Java, PL/SQL, and SQL code.

See Chapter 12, "Database Web Services" for more information and the Oracle Database JPublisher User's Guide for more information. For more details, see "Support for Calling Java Stored Procedures Directly".

1.2.4 Native Java Interface

In Oracle Database, you can now invoke public static methods of Java classes in the OracleJVM directly from Java clients without defining PL/SQL call specifications and calling these through JDBC or SQLJ. Instead, you can use the JPublisher utility to generate a client-proxy class with the same signature as the server-side Java class. Once you have instantiated a client-proxy instance with a JDBC connection, you can call the proxy methods directly.

Figure 1-1 demonstrates a client-side stub API for direct invocation of static server-side Java methods. JPublisher transparently takes care of stub generation.

Figure 1-1 Native Java Interface

For example, to call the following method in the server

public String oracle.sqlj.checker.JdbcVersion.to_string();

use

jpub -java=oracle.sqlj.checker.JdbcVersion

1.2.5 EJB Call-out

In certain enterprise applications, it becomes essential to access Enterprise Java Beans (EJB) that are deployed on a remote server from within the database. For example, if you need complex calculations, for which EJBs are perfect, you can call out to the EJB to perform those calculations. Examples of complex calculations include tax calculators. Because the EJB call-out does not currently support transactions, only stateless session beans can be used. Therefore, if a trigger calls out to an EJB and it fails, the trigger does not roll back.

Thus, through the EJB call-out, the Oracle Database provides a means to access the remotely deployed EJBs over Remote Method Invocation, or RMI.

The EJB JAR is not installed in the database in this release, so you must follow these steps to install the J2EE.JAR:

1. Load J2EE.JAR using SQL*Plus.

   sqlplus /nolog
   SQL> connect sys/password as sysdba
   SQL> set serveroutput on
   SQL> call dbms_java.set_output(4000);
   SQL> call dbms_java.loadjava (?-r -install -v -s -g public -genmissing
      absolute path to J2EE_HOME/lib/j2ee.jar?);
   
   

2. Grant the proper Java permissions; this example grants permissions to SCOTT:

   SQL> grant ejbclient to scott;
   SQL> call dbms_java.grant_permission(?SCOTT?,?SYS:java.io.FilePermission?,
        ?absolute_path_to_ORACLE_HOME/javavm/lib.orb.properties?,?read?);
   SQL> call dbms_java.grant_permission(?SCOTT?,
        ?SYS:java.net.SocketPermissino?,?localhost:1024-?,?listen,resolve?);
   SQL> call dbms_java.grant_permission(?SCOTT?,
        ?SYS:java.util.PropertyPermission?,
        ?java.naming.factory,initial?,?write?);
   SQL> call dbms_java.grant_permission(?SCOTT?, 
        ?SYS:java.lang.RuntimePermission?,?shutdownHooks?,??);
   SQL> call dbms_java.grant_permission(?SCOTT?,
        ?SYS:java.util.logging.LoggingPermission?, ?control?,??);
   SQL> call dbms_java.grant_permission(?SCOTT?,
        ?SYS:java.util.PropertyPermission?,
        ?java.naming.provider.url?,?write?);
   SQL> exit;
   
   

Once the J2EE.JAR is loaded, you can call out to EJBs from the database into the application server. The following steps show how to call out to an EJB from the database with the LoggerEJB demo (available at http://java.sun.com/j2se/1.4.1/docs/guide/rmi-iiop/interop.html), and using ojvmjava to execute the LogClient in the database. Note that the EJB application called by the following procedure must already be deployed to the application server.

1. Load the Java client into the correct schema in the database. In the LogClient example, you load the LoggerClient.jar and Logger interfaces into the scott schema from the LoggerEJB source directory. Note that the LoggerClient.jar contains the IIOP interface stubs.

   loadjava -u scott/tiger -r -v LoggerClient.jar ejbinterop/*.class
   
   

2. Execute the Java client, which calls the EJB application. Use ojvmjava to execute the client main method. The CORBA URL must be modified to know the hostname and port number on which the application server is executing and listening.

   ojvmjava -u scott/tiger -c "java LogClient"
   ojmvjava -u scott/tiger -c "java ejbinterop.LogClient   corbaname:iiop:1.2@myhost:3700#LoggerEJB"
   
   

If successful, this type of message is added to the server.log: Message from a Java RMI-IIOP client.

The previous example calls out to the EJB application using ojvmjava. If you want to call out from a PL/SQL procedure, use the following set of commands instead:

SQL> create or replace procedure myejb(args varchar2) as language java 
     name 'ejbinterop.LogClient.main('java.lang.String[])';
SQL> /
SQL> set serveroutput on
SQL> call dbms_java.set_output(40000);
SQL> call myejb('corbaname:iiop:1.2@myhost:3200#LoggerEJB

Figure 1-2 EJB Call-out

1.3.1 Java and Object-Oriented Programming Terminology

This section covers some basic terminology of Java application development in the Oracle Database environment. The terms should be familiar to experienced Java programmers. A detailed discussion of object-oriented programming or of the Java language is beyond the scope of this book. Many texts, in addition to the complete language specification, are available at your bookstore and on the Internet. See "Suggested Reading" in the Preface for pointers to reference materials and for places to find Java-related information on the Internet.

1.3.1.1 Classes

All object-oriented programming languages support the concept of a class. As with a table definition, a class provides a template for objects that share common characteristics. Each class can contain the following:

• Attributes—static or instance variables that each object of a particular class possesses.

• Methods—you can invoke methods defined by the class or inherited by any classes extended from the class.

When you create an object from a class, you are creating an instance of that class. The instance contains the fields of an object, which are known as its data, or state. Figure 1-3 shows an example of an Employee class defined with two attributes: last name (lastName) and employee identifier (ID).

Figure 1-3 Classes and Instances

When you create an instance, the attributes store individual and private information relevant only to the employee. That is, the information contained within an employee instance is known only for that single employee. The example in Figure 1-3 shows two instances of employee—Smith and Jones. Each instance contains information relevant to the individual employee.

1.3.2 Class Hierarchy

Java defines classes within a large hierarchy of classes. At the top of the hierarchy is the Object class. All classes in Java inherit from the Object class at some level, as you walk up through the inheritance chain of superclasses. When we say Class B inherits from Class A, each instance of Class B contains all the fields defined in class B, as well as all the fields defined in Class A. For example, in Figure 1-4, the FullTimeEmployee class contains the id and lastName fields defined in the Employee class, because it inherits from the Employee class. In addition, the FullTimeEmployee class adds another field, bonus, which is contained only within FullTimeEmployee.

You can invoke any method on an instance of Class B that was defined in either Class A or B. In our employee example, the FullTimeEmployee instance can invoke methods defined only within its own class, or methods defined within the Employee class.

Figure 1-4 Class Hierarchy

Instances of Class B are substitutable for instances of Class A, which makes inheritance another powerful construct of object-oriented languages for improving code reuse. You can create new classes that define behavior and state where it makes sense in the hierarchy, yet make use of pre-existing functionality in class libraries.

1.3.3 Interfaces

Java supports only single inheritance; that is, each class has one and only one class from which it inherits. If you must inherit from more than one source, Java provides the equivalent of multiple inheritance, without the complications and confusion that usually accompany it, through interfaces. Interfaces are similar to classes; however, interfaces define method signatures, not implementations. The methods are implemented in classes declared to implement an interface. Multiple inheritance occurs when a single class simultaneously supports many interfaces.

1.3.4 Polymorphism

Assume in our Employee example that the different types of employees must be able to respond with their compensation to date. Compensation is computed differently for different kinds of employees.

• FullTimeEmployees are eligible for a bonus

• NonExemptEmployees get overtime pay

In traditional procedural languages, you would write a long switch statement, with the different possible cases defined.

switch: (employee.type) {

          case: Employee             return employee.salaryToDate;           case: FullTimeEmployee             return employee.salaryToDate + employee.bonusToDate          ...

If you add a new kind of Employee, you must update your switch statement. If you modify your data structure, you must modify all switch statements that use it. In an object-oriented language such as Java, you implement a method, compensationToDate(), for each subclass of Employee class that requires any special treatment beyond what is already defined in Employee class. For example, you could implement the compensationToDate() method of NonExemptEmployee, as follows:

private float compensationToDate() {          return super.compensationToDate() + this.overtimeToDate(); }

You implement FullTimeEmployee's method, as follows:

private float compensationToDate() {          return super.compensationToDate() + this.bonusToDate(); }

The common usage of the method name compensationToDate() allows you to invoke the identical method on different classes and receive different results, without knowing the type of employee you are using. You do not have to write a special method to handle FullTimeEmployees and PartTimeEmployees. This ability for the different objects to respond to the identical message in different ways is known as polymorphism.

In addition, you could create an entirely new class that does not inherit from Employee at all—Contractor—and implement a compensationToDate() method in it. A program that calculates total payroll to date would iterate over all people on payroll, regardless of whether they were full-time, part-time, or contractors, and add up the values returned from invoking the compensationToDate() method on each. You can safely make changes to the individual compensationToDate() methods with the knowledge that callers of the methods will work correctly. For example, you can safely add new fields to existing classes.

1.3.5 The Java Virtual Machine (JVM)

As with other high-level computer languages, your Java source compiles to low-level machine instructions. In Java, these instructions are known as bytecodes (because their size is uniformly one byte of storage). Most other languages—such as C—compile to machine-specific instructions—such as instructions specific to an Intel or HP processor. Your Java source compiles to a standard, platform-independent set of bytecodes, which interacts with a Java virtual machine (JVM). The JVM is a separate program that is optimized for the specific platform on which you execute your Java code. Figure 1-5 illustrates how Java can maintain platform independence. Your Java source is compiled into bytecodes, which are platform independent. Each platform has installed a JVM that is specific to its operating system. The Java bytecodes from your source get interpreted through the JVM into appropriate platform dependent actions.

Figure 1-5 Java Component Structure

When you develop a Java program, you use predefined core class libraries written in the Java language. The Java core class libraries are logically divided into packages that provide commonly-used functionality, such as basic language support (java.lang), input/output (java.io), and network access (java.net). Together, the JVM and core class libraries provide a platform on which Java programmers can develop with the confidence that any hardware and operating system that supports Java will execute their program. This concept is what drives the "write once, run anywhere" idea of Java.

Figure 1-6 illustrates how Oracle Java applications sit on top of the Java core class libraries, which in turn sit on top of the JVM. Because the Oracle Java support system is located within the database, the JVM interacts with the Oracle database libraries, instead of directly with the operating system.

Figure 1-6 Oracle Database Java Component Structure

Sun Microsystems furnishes publicly available specifications for both the Java language and the JVM. The Java Language Specification (JLS) defines things such as syntax and semantics; the JVM specification defines the necessary low-level behavior for the "machine" that executes the bytecodes. In addition, Sun Microsystems provides a compatibility test suite for JVM implementors to determine if they have complied with the specifications. This test suite is known as the Java Compatibility Kit (JCK). The OracleJVM implementation complies fully with JCK. Part of the overall Java strategy is that an openly specified standard, together with a simple way to verify compliance with that standard, allows vendors to offer uniform support for Java across all platforms.

1.3.6 Key Features of the Java Language

The Java language has key features that make it ideal for developing server applications. These features include:

• Simplicity—Java is a simpler language than most others used in server applications because of its consistent enforcement of the object model. The large, standard set of class libraries brings powerful tools to Java developers on all platforms.

• Portability—Java is portable across platforms. It is possible to write platform-dependent code in Java, but it is also simple to write programs that move seamlessly across machines. Oracle server applications, which do not support graphical user interfaces directly on the platform that hosts them, also tend to avoid the few platform portability issues that Java has.

• Automatic Storage Management—The Java virtual machine automatically performs all memory allocation and deallocation during program execution. Java programmers can neither allocate nor free memory explicitly. Instead, they depend on the JVM to perform these bookkeeping operations, allocating memory as they create new objects and deallocating memory when the objects are no longer referenced. The latter operation is known as garbage collection.

• Strong Typing—Before you use a Java variable, you must declare the class of the object it will hold. Java's strong typing makes it possible to provide a reasonable and safe solution to inter-language calls between Java and PL/SQL applications, and to integrate Java and SQL calls within the same application.

• No Pointers—Although Java retains much of the flavor of C in its syntax, it does not support direct pointers or pointer manipulation. You pass all parameters, except primitive types, by reference (that is, object identity is preserved), not by value. Java does not provide C's low level, direct access to pointers, which eliminates memory corruption and leaks.

• Exception Handling—Java exceptions are objects. Java requires developers to declare which exceptions can be thrown by methods in any particular class.

• Flexible Namespace—Java defines classes and holds them within a hierarchical structure that mirrors the Internet's domain namespace. You can distribute Java applications and avoid name collisions. Java extensions such as the Java Naming and Directory Interface (JNDI) provide a framework for multiple name services to be federated. Java's namespace approach is flexible enough for Oracle to incorporate the concept of a schema for resolving class names, while fully complying with the language specification.

• Security—The design of Java bytecodes and the JVM allow for built-in mechanisms to verify that the Java binary code was not tampered with. Oracle Database is installed with an instance of SecurityManager, which, when combined with Oracle database security, determines who can invoke any Java methods.

• Standards for Connectivity to Relational Databases—JDBC and SQLJenable Java code to access and manipulate data resident in relational databases. Oracle provides drivers that allow vendor-independent, portable Java code to access the relational database.

1.5.1 Multithreading

Multithreading support is often cited as one of the key scalability features of the Java language. Certainly, the Java language and class libraries make it simpler to write multithreaded applications in Java than many other languages, but it is still a daunting task in any language to write reliable, scalable multithreaded code.

As a database server, Oracle Database efficiently schedules work for thousands of users. The OracleJVM uses the facilities of the RDBMS server to concurrently schedule Java execution for thousands of users. Although Oracle Database supports Java language level threads required by the JLS and JCK, using threads within the scope of the database will not increase your scalability. Using the embedded scalability of the database eliminates the need for writing multithreaded Java servers. You should use the database's facilities for scheduling users by writing single-threaded Java applications. The database will take care of the scheduling between each application; thus, you achieve scalability without having to manage threads. You can still write multithreaded Java applications, but multiple Java threads will not increase your server's performance.

One difficulty multithreading imposes on Java is the interaction of threads and automated storage management, or garbage collection. The garbage collector executing in a generic JVM has no knowledge of which Java language threads are executing or how the underlying operating system schedules them.

• Non-Oracle Database model—A single user maps to a single Java language level thread; the same single garbage collector manages all garbage from all users. Different techniques typically deal with allocation and collection of objects of varying lifetimes and sizes. The result in a heavily multithreaded application is, at best, dependent upon operating system support for native threads, which can be unreliable and limited in scalability. High levels of scalability for such implementations have not been convincingly demonstrated.

• OracleJVM model—Even when thousands of users connect to the server and execute the same Java code, each user experiences it as if he is executing his own Java code on his own Java virtual machine. The responsibility of the OracleJVM is to make use of operating system processes and threads, using the scalable approach of the Oracle RDBMS. As a result of this approach, the JVM's garbage collector is more reliable and efficient because it never collects garbage from more than one user at any time. Refer to "Threading in Oracle Database" for more information on the thread model implementation in OracleJVM.

1.5.2 Automated Storage Management With Garbage Collection

Garbage collection is a major feature of Java's automated storage management, eliminating the need for Java developers to allocate and free memory explicitly. Consequently, this eliminates a large source of memory leaks that commonly plague C and C++ programs. There is a price for such a benefit: garbage collection contributes to the overhead of program execution speed and footprint. Although many papers have been written qualifying and quantifying the trade-off, the overall cost is reasonable, considering the alternatives.

Garbage collection imposes a challenge to the JVM developer seeking to supply a highly scalable and fast Java platform. The OracleJVM meets these challenges in the following ways:

• The OracleJVM uses the Oracle Database scheduling facilities, which can manage multiple users efficiently.

• Garbage collection is performs consistently for multiple users because garbage collection is focused on a single user within a single session. The OracleJVM enjoys a huge advantage because the burden and complexity of the memory manager's job does not increase as the number of users increases. The memory manager performs the allocation and collection of objects within a single session—which typically translates to the activity of a single user.

• The OracleJVM uses different garbage collection techniques depending on the type of memory used. These techniques provide high efficiency and low overhead.

1.5.3 Footprint

The footprint of an executing Java program is affected by many factors:

• Size of the program itself—how many classes and methods and how much code they contain.

• Complexity of the program—the amount of core class libraries that the OracleJVM uses as the program executes, as opposed to the program itself.

• Amount of state the JVM uses—how many objects the JVM allocates, how large they are, and how many must be retained across calls.

• Ability of the garbage collector and memory manager to deal with the demands of the executing program, which is often non-deterministic. The speed with which objects are allocated and the way they are held on to by other objects influences the importance of this factor.

From a scalability perspective, the key to supporting many concurrent clients is a minimum per-user session footprint. The OracleJVM keeps the per-user session footprint to a minimum by placing all read-only data for users, such as Java bytecodes, in shared memory. Appropriate garbage collection algorithms are applied against call and session memories to maintain a small footprint for the user's session. The OracleJVM uses three types of garbage collection algorithms to maintain the user's session memory:

• generational scavenging for short-lived objects

• mark and lazy sweep collection for objects that exist for the life of a single call

• copying collector for long-lived objects—objects that live across calls within a session

1.5.4 Performance

OracleJVM performance is enhanced by implementing a native compiler.

1.5.4.1 How Native Compilers Improve Performance

Java executes platform-independent bytecodes on top of a JVM, which in turn interacts with the specific hardware platform. Any time you add levels within software, your performance is degraded. Because Java requires going through an intermediary to interpret platform-independent bytecodes, a degree of inefficiency exists for Java applications that does not exists within a platform-dependent language, such as C. To address this issue, several JVM suppliers create native compilers. Native compilers translate Java bytecodes into platform-dependent native code, which eliminates the interpreter step and improves performance.

The following describes two methods for native compilation:

Compiler	Description
Just-In-Time (JIT) Compilation	JIT compilers quickly compile Java bytecodes to native (platform-specific) machine code during runtime. This does not produce an executable to be executed on the platform; instead, it provides platform-dependent code from Java bytecodes that is executed directly after it is translated. This should be used for Java code that is run frequently, which will be executed at speeds closer to languages such as C.
Ahead-of-Time Compilation	Compilation translates Java bytecodes to platform-independent C code before runtime. Then a standard C compiler compiles the C code into an executable for the target platform. This approach is more suitable for Java applications that are modified infrequently. This approach takes advantage of the mature and efficient platform-specific compilation technology found in modern C compilers.

Oracle Database uses Ahead-of-Time compilation to deliver its core Java class libraries: JDBC code in natively compiled form. It is applicable across all the platforms Oracle supports, whereas a JIT approach requires low-level, processor-dependent code to be written and maintained for each platform. You can use this native compilation technology with your own Java code.

As Figure 1-8 shows, natively compiled code executes up to ten times faster than interpreted code. So, the more native code your program uses, the faster it executes.

Figure 1-8 Interpreter versus Accelerator

Refer to "Natively Compiled Code" for more information.

1.5.5 Dynamic Class Loading

Another strong feature of Java is dynamic class loading. The class loader loads classes from the disk (and places them in the JVM-specific memory structures necessary for interpretation) only as they are used during program execution. The class loader locates the classes in the CLASSPATH and loads them during program execution. This approach, which works well for applets, poses the following problems in a server environment:

1.6.1 Method main()

Client-based Java applications declare a single, top-level method (main()) that defines the profile of an application. As with applets, server-based applications have no such "inner loop." Instead, they are driven by logically independent clients.

Each client begins a session, calls its server-side logic modules through top-level entry points, and eventually ends the session. The server environment hides the managing of sessions, networks, and other shared resources from hosted Java programs.

1.6.2 The GUI

A server cannot provide GUIs, but it can supply the logic that drives them. The OracleJVM supports only the headless mode of the Abstract Windowing Toolkit (AWT). All AWT Java classes are available within the server environment and your programs can use AWT functionality, as long as they do not attempt to materialize a GUI on the server. For more information, see "User Interfaces on the Server".

1.6.3 The IDE

The OracleJVM is oriented to Java application deployment, not development. You can write and unit-test applications in your favorite IDE, such as Oracle JDeveloper, then deploy them for execution within the RDBMS.

Java's binary compatibility enables you to work in any IDE, then upload Java class files to the server. You need not move your Java source files to the database. Instead, you can use powerful client-side IDEs to maintain Java applications that are deployed on the server.

1.7.1 Library Manager

To store Java classes in an Oracle database, you use the command-line utility loadjava, which employs SQL CREATE JAVA statements to do its work. When invoked by the CREATE JAVA {SOURCE | CLASS | RESOURCE} statement, the library manager loads Java source, class, or resource files into the database. You never access these Java schema objects directly; only the OracleJVM uses them.

1.7.2 Compiler

The OracleJVM includes a standard Java 2 (also known as JDK 1.2) Java compiler. When invoked by the CREATE JAVA SOURCE statement, it translates Java source files into architecture-neutral, one-byte instructions known as bytecodes. Each bytecode consists of an opcode followed by its operands. The resulting Java class files, which conform fully to the Java standard, are submitted to the interpreter at run time.

1.7.3 Interpreter

To execute Java programs, the OracleJVM includes a standard Java 2 bytecode interpreter. The interpreter and associated Java run-time system execute standard Java class files. The run-time system supports native methods and call-in/call-out from the host environment.

1.7.4 Class Loader

In response to requests from the run-time system, the Java class loader locates, loads, and initializes Java classes stored in the database. The class loader reads the class, then generates the data structures needed to execute it. Immutable data and metadata are loaded into initialize-once shared memory. As a result, less memory is required for each session. The class loader attempts to resolve external references when necessary. Also, it invokes the Java compiler automatically when Java class files must be recompiled (and the source files are available).

1.7.5 Verifier

Java class files are fully portable and conform to a well-defined format. The verifier prevents the inadvertent use of "spoofed" Java class files, which might alter program flow or violate access restrictions. Oracle security and Java security work with the verifier to protect your applications and data.

1.7.6 Server-Side JDBC Internal Driver

JDBC is a standard set of Java classes providing vendor-independent access to relational data. Specified by Sun Microsystems and modeled after ODBC (Open Database Connectivity) and the X/Open SQL CLI (Call Level Interface), the JDBC classes supply standard features such as simultaneous connections to several databases, transaction management, simple queries, calls to stored procedures, and streaming access to LONG column data.

Using low-level entry points, a specially tuned JDBC driver runs directly inside the RDBMS, thereby providing the fastest access to Oracle data from Java stored procedures. The server-side internal JDBC driver complies fully with the Sun Microsystems JDBC specification. Tightly integrated with the RDBMS, it supports Oracle-specific data types, globalization character sets, and stored procedures. Additionally, the client-side and server-side JDBC APIs are the same, which makes it easy to partition applications.

1.8.1 Java Programming Environment

In addition to the OracleJVM, the Java programming environment consists of:

• Java stored procedures as the Java equivalent and companion for PL/SQL. Java stored procedures are tightly integrated with PL/SQL. You can call a Java stored procedure from a PL/SQL package; you can call PL/SQL procedures from a Java stored procedure.

• SQL data can be accessed through JDBC and SQLJ programming interfaces.

• Tools and scripts used in assisting in development, class loading, and class management.

To help you decide which Java APIs to use, examine the following table:

1.8.2 Java Stored Procedures

If you are a PL/SQL programmer exploring Java, you will be interested in Java stored procedures. A Java stored procedure is a program you write in Java to execute in the server, exactly as a PL/SQL stored procedure. You invoke it directly with products like SQL*Plus, or indirectly with a trigger. You can access it from any Oracle Net client—OCI, PRO* or JDBC or SQLJ. Chapter 5, "Developing Java Stored Procedures" explains how to write stored procedures in Java, how to access them from PL/SQL, and how to access PL/SQL functionality from Java.

In addition, you can use Java to develop powerful programs independently of PL/SQL. Oracle Database provides a fully-compliant implementation of the Java programming language and JVM.

1.8.3 PL/SQL Integration and Oracle RDBMS Functionality

You can invoke existing PL/SQL programs from Java and invoke Java programs from PL/SQL. This solution protects and leverages your existing investment while opening up the advantages and opportunities of Java-based Internet computing.

Oracle offers two different application programming interfaces (APIs) for Java developers to access SQL data—JDBCand SQLJ. Both APIs are available on client and server, so you can deploy the same code in either place.

• JDBC Drivers

• JPublisher

1.8.4 Development Tools

The introduction of Java to the Oracle Database server allows you to use several Java Integrated Development Environments. The adherence of Oracle Database to Java compatibility and open Internet standards and protocols ensures that your 100% pure Java programs work when you deploy them on Oracle Database. Oracle delivers many tools or utilities, all written in Java, that make development and deployment of Java server applications easier. Oracle's JDeveloper has many features designed specifically to make deployment of Java stored procedures and Enterprise JavaBeans easier. You can download JDeveloper at the following site: http://otn.oracle.com/software/products/jdev/content.html.