Release 8.1.5
A64682-01
Library |
Product |
Contents |
Index |
| Oracle8i
Java Developer's Guide
Release 8.1.5 A64682-01 |
|
This chapter introduces the Java language to Oracle users.
Oracle PL/SQL developers are accustomed to developing server-side applications
that have tight integration with SQL data. This world is now available
to Java developers, with the scalability and performance of Oracle. This
chapter begins with a roadmap to Oracle8i Java documentation, then
examines Oracle's overall Java strategy, designed to deliver a complete
solution for enterprise application development in Java. A key element
of that strategy is the introduction of Oracle's scalable Java server platform--the
Oracle JServer. With that background, we explore the Java language so that
we can move on to discuss the specifics of the JServer implementation in
the next chapter.
This Guide is the starting point for Oracle8i Java
developers. A key goal of Oracle's JServer is to provide an industry-standard
Java implementation, while achieving the robustness, scalability, and performance
Oracle users have come to expect. This Guide outlines some of the unique
features of Java programming with Oracle8i, including aspects of
the Oracle Java virtual machine, explaining how to take advantage of these
features in your Java programs. Using Java and Oracle8i, you can
build and deploy powerful server-based Java applications shared by all
clients. These applications can easily be distributed across networks,
providing access to Oracle data from any computer that supports Java.
Oracle8i Java developers should become familiar with Oracle's
Java Database Connectivity (JDBC) product because it provides the basis
for accessing SQL data from Java programs, as well as Oracle-specific extensions
to this Java standard. In addition, you may find it easier to develop Java
programs that access SQL data using embedded SQL in Java (SQLJ). SQLJ uses
a preprocessor, written in Java, to translate embedded SQL statements to
standard JDBC-style programs. Both JDBC and SQLJ are industry standards.
The Oracle8i JDBC Developer's Guide and Reference and the Oracle8i SQLJ
Developer's Guide and Reference document these industry standards and Oracle
specific enhancements in detail. The Oracle8i JPublisher User's Guide documents
JPublisher, which provides a simple and convenient tool to create Java
programs that access existing Oracle relational database tables.
If you are a PL/SQL programmer exploring Java, then you should
read the Oracle8i Java Stored Procedures Developer's Guide. 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 and can access it from any Net8 client--OCI,
PRO*, JDBC or SQLJ. The Oracle8i Java Stored Procedures Developer's
Guide explains how to write stored procedures in Java, how to access them
from PL/SQL, and how to access PL/SQL functionality from Java. Of course,
you can use Java to develop powerful programs independently of PL/SQL,
and Oracle8i provides a fully compliant implementation of the Java
programming language and virtual machine.
The Oracle8i Enterprise JavaBeans and CORBA Developer's
Guide and Reference describes how to take advantage of Oracle's open distributed
object technology, including its Object Request Broker (the Aurora/ORB)
and Enterprise JavaBeans (EJB) functionality. The Aurora/ORB and EJB furnish
powerful standards-based frameworks and tools to help you build scalable
Java applications that provide seamless transactional access to Oracle
data across your intranet or the Internet.
For the most up-to-date information on Oracle's Java offerings,
updates, and news, always consult:
Oracle's Java web site contains Frequently Asked Questions
(FAQ) documents, updated JDBC drivers and "reference" SQLJ implementations,
white papers with detailed technical information on Java application development,
as well as try-and-buy downloadable tools.
The central source for general Java information and documentation
is Sun Microsystems:
At Sun's site, you will find current versions of the Java
Development Kit (JDK) and other Sun products available at:
The Oracle8i JServer implementation is based on the
publicly available Java Language Specification (JLS) and the Java Virtual
Machine Specification. You will find these specifications on-line at:
http://java.sun.com/docs/books/jls
http://java.sun.com/docs/books/vmspec
Internet newsgroups are a valuable source of information
on Java and the experience of Java developers. Some of the more useful
Java-oriented newsgroups include:
Oracle monitors activity on some of these newsgroups and
actively posts responses to Oracle-specific issues.
Your local or on-line bookstore has many useful Java references.
You can find some materials most helpful to beginners and that you can
use as general references, in the Oracle8i Java Stored Procedures
Developer's Guide.
Oracle furnishes enterprise application developers with an
end-to-end Java solution--a high-performance, scalable infrastructure to
deploy Java applications and a rich set of Java tools that ties this infrastructure
together. The total solution consists of client- and server-side programmatic
interfaces, tools to support Java development, and most importantly, a
Java virtual machine integrated with the Oracle8i database server.
All these products provide a highly productive programming model, optimized
performance and scalability, and are 100 percent compatible with Java standards.
Together, they make Oracle8i and its Java server platform, JServer,
the database and Java platform for Internet computing.
Oracle offers two different application programming interfaces
(APIs) for Java developers to access SQL data--JDBC and SQLJ. Both APIs
are available on client and server, so you can deploy the same code in
either place.
Core Java class libraries provide only one JDBC API. JDBC
is designed, however, to allow vendors to supply drivers that offer the
necessary specialization for a particular database. Oracle delivers JServer
with three distinct JDBC drivers.
You can use the JDBC thin driver to write 100% pure Java
applications and applets that access Oracle SQL data. The JDBC thin driver
is especially well suited to Web browser-based applications and applets
because you can dynamically download it from a Web page just like any other
Java applet. As an alternative, you can use the JDBC Oracle Call Interface
(OCI) driver, which accesses Oracle-specific native code (that is, non-Java)
libraries on the client or middle tier, providing a richer set of functionality
and some performance boost compared to the JDBC thin driver, at the cost
of significantly larger size. Finally, the JServer introduces a JDBC server
driver that you use when Java code executes on the Oracle8i server.
It allows Java applications executing in the server's Java virtual machine
to access locally defined data (that is, on the same machine and in the
same process) with JDBC. It provides a further performance boost because
of its ability to use underlying Oracle RDBMS libraries directly, without
the overhead of an intervening network connection between your Java code
and SQL data. By supporting the same Java-SQL interface on the server,
Oracle 8i does not require you to rework code when deploying it.
JDBC provides a low-level API for accessing SQL data from
Java. It introduces Java classes that mirror their SQL equivalents. Oracle
has worked with other vendors, including IBM, Tandem, Sybase, and Sun Microsystems,
to develop a standard way to embed SQL statements in Java programs--SQLJ.
This work has resulted in a new standard (ANSI x.3.135.10-1998) for a simpler
and more highly productive programming API than JDBC. A user writes applications
to this higher level API and then employs a standard preprocessor to translate
the program to standard Java source with JDBC calls. At runtime, the program
can communicate with multi-vendor databases using standard JDBC drivers.
SQLJ provides a simple but powerful way to develop both client-side and
middle-tier applications that access databases from Java. You can use it
in stored procedures, triggers, methods within the JServer environment,
and with EJB and CORBA. In addition, you can combine SQLJ programs with
JDBC.
The SQLJ translator is a Java program that translates embedded
SQL in Java source code to pure JDBC-based Java code. Because JServer provides
a complete Java environment, you can not only compile SQLJ programs on
a client for execution on the JServer, but you can compile them directly
on the server. Oracle8i's adherence to Internet standards allows
you to choose the development style that fits your needs.
In addition to server-side support for the APIs discussed in the preceding section, the JServer Environment consists of:
The Java virtual machine executes Java programs on the Oracle8i
server. In this chapter and in Chapter 2, we will discuss what a virtual
machine does in some detail and why Oracle's Aurora virtual machine offers
the most scalable, enterprise-level implementation available.
One appeal of Java is its ubiquity and the growing number
of programmers capable of developing applications using it. Existing Oracle-based
server applications almost exclusively use PL/SQL. Oracle8i allows you
to write and execute programs such as stored procedures, triggers, and
Object Type methods in Java, to invoke existing PL/SQL programs from Java
and to 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.
In addition to support for traditional RDBMS-stored procedures,
JServer comes with a built-in CORBA 2.0-compliant ORB (Inprise VisiBroker
for Java 3.2) and support for Enterprise JavaBeans (EJB). The ORB allows
programs you develop in any language to communicate directly with the Oracle8i
database through the Internet Inter-ORB Protocol (IIOP), the standard wire-protocol
defined by the Object Management Group (OMG). For 100% pure Java applications,
EJB is the standard framework for deploying component-based, secure, transactional
applications on JServer. CORBA and EJB allow you to distribute Java components
and application logic between client, middle-tier, and database server.
The introduction of Java to the Oracle8i server allows
you to use several Java Integrated Development Environments. JServer's
adherence to Java compatibility and open Internet standards and protocols
ensure that your 100% pure Java programs work when you deploy them on JServer.
Oracle delivers JServer with 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.
Java has emerged over the last several years as the object-oriented
programming language of choice. The language was developed at Sun Microsystems,
whose language designers drew from the experience of several earlier languages
to produce Java. For example, the concept of a virtual machine, which provides
the fundamental basis for platform independence that is much touted in
Java, was pioneered by Smalltalk and LISP. Automated storage management
techniques, the most visible of which is garbage collection, are also featured
in LISP and Smalltalk. While borrowing from these innovative pioneering
efforts in object-oriented programming, Java's designers also chose to
adhere to a language syntax that borrows from C and to enforce strong typing.
The result is language easily learned by the huge body of existing C programmers
but that remains truly object-oriented and efficient for application-level
programs.
A detailed discussion of object-oriented programming in general
and of the Java language in specific is beyond the scope of this book.
Many excellent texts, in addition to the complete language specification,
are readily available at your bookstore and on the Internet. In fact, the
proliferation of reference material on Java and the rapidly evolving variety
of Java class libraries and frameworks are key elements in its success.
See "Java Information Resources" in this chapter, and "Suggested Reading"
in the Oracle8i Java Stored Procedures Developer's Guide for pointers to
reference materials and places to find Java-related information on the
Internet.
This section covers some basic terminology to establish enough
common ground to discuss details of Java application development in the
Oracle8i environment. The terms we use should be familiar to experienced
Java programmers. If you are not comfortable with the terms and concepts
we discuss here, you may want to review some of your Java books or look
up some of the Web sites discussed in the section "Java Information Resources"
in this chapter.
All object-oriented programming languages support the concept
of a class. (This Guide adheres to Java nomenclature; other languages use
similar terms.) As with a table definition, a class provides a template
for objects that share common characteristics, defining the "attributes"
that each object of a particular class possesses. For example, the Employee
class could specify that each employee consists of a last name, first name,
and employee ID. Each instance of Employee has these three attributes;
however, these attributes are individual and private to each instance.
In Java, attributes of an instance are known as fields. Instance fields
are analogous to the fields of a relational table row. The class defines
the fields, as well as the type of each field. You can declare fields in
Java to be public, private, protected, or default access. Classes also
have fields, known as static fields. Unlike instance fields, only one copy
of a class' static fields is maintained, no matter how many instances are
created. The language specification defines the rules of visibility of
data in fields (under what circumstances in Java code you can access the
data in these fields).
Each instance of a class is an object. The fields of an object
are its data, or state. In addition to the kinds of data that make up each
object, the class also defines the methods that you can invoke on an instance
of that class. Methods are written in Java, and collectively, they define
the behavior of an object. This bundling of state and behavior is the essence
of encapsulation, a feature of all object-oriented programming languages.
If you define an Employee class as before and declare that each
Employee's ID is a private field, then the only way any other object can
determine what object is contained in the ID field is to invoke the Employee.getId()
method. Furthermore, you can declare that the Employee.getId()
method is private, or you need not even write an Employee.getId()
method at all. Encapsulation helps you write programs that are more easily
reused and inherently less open to inadvertent misuse. Encapsulation makes
public only those features of an object that are important to those who
will use the object, while hiding those features that are useful only to
the developer of the object.
Finally, an overview of object-oriented terminology would not be complete without mentioning 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--all FullTimeEmployees are eligible for a bonus, but only 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, then you must update your switch statement (and in fact, each switch statement you use to implement any similar functionality). If you modify your data structure, then you must modify all switch statements that use it. In an object-oriented language such as Java, you would instead write a method known as compensationToDate() for each subclass of Employee class that required any special treatment beyond what was already defined in Employee class. For example, the compensationToDate() method of NonExemptEmployee could look like this:
private float compensationToDate() { return super.compensationToDate() + this.overtimeToDate(); }
and FullTimeEmployee's method would look like:
private float compensationToDate() { return super.compensationToDate() + this.bonusToDate(); }
The common usage of the method name compensationToDate()
allows us to invoke the same method on different classes and receive different
results without actually knowing or caring which type of employee we are
working with. We do not have to write a specially named method to handle
FullTimeEmployees and PartTimeEmployees; in fact we should
not. Furthermore, we 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 simply
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 without change; you can
safely add new fields to existing classes. This ability for the different
objects to respond to the same message in different ways is known as polymorphism,
a powerful technique for producing reusable and easily extensible code.
Just as any other high-level computer language does, Java
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;
that is, instructions specific to an Intel Pentium or HP processor. Java
compiles to a standard, platform-independent set of bytecodes for a virtual
machine--one that does not really exist. The virtual machine is written
as a separate program optimized for the specific platform on which you
execute Java. When you use Java in your Netscape browser on a Sun workstation,
the virtual machine, a separate executable program written for the Solaris
platform, executes the Java bytecodes. The JServer Java virtual machine
is written in C.
When you develop a Java program, you make use of predefined
core class libraries written in the Java language. The Java core class
libraries are logically divided into packages that provide commonly used
functionality for areas like basic language support (java.lang),
input/output (java.io), network access (java.net), and
so on. Together, the virtual machine and core class libraries provide a
platform for 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.
Sun furnishes publicly available specifications for both
the Java language and the virtual machine. The language specification defines
things such as syntax and semantics; the virtual machine specification
defines the necessary low-level behavior for the "machine" that executes
the bytecodes. In addition, Sun provides a compatibility test suite for
virtual machine implementers to determine if they have complied with the
specifications (and thus, that virtually all 100% pure Java programs will
run correctly on the implementation). This test suite is known as the Java
Compatibility Kit (JCK). Oracle's virtual machine implementation complies
fully with JCK. Part of the overall Java strategy is that an openly specified
standard, having a simple way to verify compliance with that standard,
will allow vendors to offer uniform support for Java across all platforms.
Oracle's compliance with the JCK demonstrates its commitment to Java as
a cross-platform language and to providing our customers with an open server
platform built on Internet standards.
Java executes in the Oracle8i server. We refer to
a Java-enabled Oracle8i database as the Oracle JServer platform.
We call the Oracle8i Java virtual machine Aurora. As a user who
executes Java code, you must establish a session in the server. The word
session as we employ it here is identical to the standard Oracle
(or any other database server) usage. A session is typically, although
not necessarily, bounded by the time a single user connects to the server.
When a user causes Java code to execute within a session, we refer to it
as a call. You can initiate a call in different ways. It can start
when a SQL client program executes a top-level Java stored procedure. You
can initiate it by invoking a method on a CORBA object or by a PL/SQL program
that calls some Java code. In all cases, a call begins, some combination
of Java, SQL, or PL/SQL code is executed to completion, and the call ends.
Oracle8i adheres to standard Java language semantics,
including dynamic class loading at runtime. During a call, you can store
objects in static fields of different classes and you can expect this state
to be available for your next call. In fact, the entire state of your Java
program (specifically, as held and reachable from all static variables)
is private to you and exists for your entire session. Ensuring that this
happens is the job of Aurora's memory manager, which we will discuss in
more detail later in this Guide.
In most Java development environments, Java source code,
binaries, and resources are stored as files in a file system. In this case,
people tend to refer to source code as .java files and compiled
Java (binaries) as .class files. Resources are any data files,
such as .properties files, that are held within the file system
hierarchy that holds source and binaries and that are loaded or used at
runtime. When you execute Java, you specify a CLASSPATH, which
is a set of a file system tree roots containing your files. Java also provides
a way to group these files into a single archive form--a ZIP or
JAR file.
In the JServer environment, source, classes, and resources
reside within the Oracle8i database. We refer to them as Java schema
objects, of which there are three types: source, class, and resource. There
are no .java, .class, or .properties files on
the server, but there are source and class Java schema objects. Instead
of a CLASSPATH, you can use a resolver to specify one or more
schemas within which to locate source, class, and resource Java schema
objects.
To summarize, we will be using the terms call and
session during our discussions. Although these terms are not Java
terms, they are server terms that apply to the Oracle8i JServer
platform. The Aurora memory manager preserves Java program state throughout
your session (that is, between calls). The JServer uses the Oracle database
to hold Java source, classes, and resources within a schema--Java schema
objects. You can use a resolver to specify how Java, when executed in the
server, locates source code, classes, and resources.
We will supply examples (e.g. in Some
Simple Examples) that apply all of the concepts this Guide discusses.
