Skip Headers

Oracle9i SQLJ Developer's Guide and Reference
Release 2 (9.2)
Part Number A96655-01
Go To Documentation Library
Home		 Go To Product List
Book List		 Go To Table Of Contents
Contents		 Go To Index
Index
Master Index
Feedback

Go to previous page Go to next page

1
Overview

This chapter provides a general overview of SQLJ features and scenarios. The following topics are discussed:

Introduction to SQLJ

This section introduces the basic concepts of SQLJ and discusses the complementary relationship between Java and PL/SQL in Oracle applications.

Basic Concepts

SQLJ enables applications programmers to embed SQL operations in Java code in a way that is compatible with the Java design philosophy. A SQLJ program is a Java program containing embedded SQL statements that comply with the ISO standard SQLJ Language Reference syntax. Oracle9i SQLJ supports the ISO SQLJ standard specification. The standard covers only static SQL operations--those that are predefined and do not change in real-time as a user runs the application (although the data values that are transmitted can change dynamically). Oracle SQLJ also offers extensions to support dynamic SQL operations--those that are not predefined, where the operations themselves can change in real-time. (It is also possible to use dynamic SQL operations through JDBC code or PL/SQL code within a SQLJ application.) Typical applications contain much more static SQL than dynamic SQL.

SQLJ consists of both a translator and a runtime component and is smoothly integrated into your development environment. The developer runs the translator, with translation, compilation, and customization (for ISO standard code) taking place in a single step when the sqlj front-end utility is run. The translation process replaces embedded SQL with calls to the SQLJ runtime, which implements the SQL operations. In ISO standard SQLJ this is typically, but not necessarily, performed through calls to a JDBC driver. To access an Oracle database, you would typically use an Oracle JDBC driver. When the end user runs the SQLJ application, the runtime is invoked to handle the SQL operations.

The Oracle SQLJ translator is conceptually similar to other Oracle precompilers and allows the developer to check SQL syntax, verify SQL operations against what is available in the schema, and check the compatibility of Java types with corresponding database types. In this way, errors can be caught by the developer instead of by a user at runtime. The translator checks the following:

The SQLJ methodology of embedding SQL operations directly in Java code is much more convenient and concise than the JDBC methodology. In this way, SQLJ reduces development and maintenance costs in Java programs that require database connectivity.

Oracle-Specific Code Generation Versus ISO Standard Code Generation

While the Oracle SQLJ implementation supports the ISO SQLJ standard, it also offers the option of Oracle-specific code generation, where Oracle JDBC calls are generated directly into the code. As of Oracle9i release 2, this is the default behavior. In the case of Oracle-specific code generation, be aware of the following:

Much of the SQLJ introductory discussion in this chapter mentions features of ISO standard code, so be aware of these key differences in Oracle-specific code.

For more information, see "Oracle-Specific Code Generation (No Profiles)".

Java and SQLJ Versus PL/SQL

Java (including SQLJ) in Oracle applications does not replace PL/SQL. Java and PL/SQL are complementary to each other in the needs they serve.

While PL/SQL and Java can both be used to build database applications, the two languages were designed with different intents and, as a result, are suited for different kinds of applications:

Oracle provides easy interoperability between PL/SQL and Java, ensuring that you can take advantage of the strengths of both languages. PL/SQL programs can transparently call Java stored procedures, enabling you to build component-based Enterprise JavaBeans applications. PL/SQL programs can have transparent access to a wide variety of existing Java class libraries through PL/SQL call specifications.

Java programs can call PL/SQL stored procedures and anonymous blocks through JDBC or SQLJ. In particular, SQLJ provides syntax for calling stored procedures and functions from within a SQLJ statement, and also supports embedded PL/SQL anonymous blocks within a SQLJ statement.

Note:

Using PL/SQL anonymous blocks within SQLJ statements is one way to support dynamic SQL in a SQLJ application. However, Oracle9i SQLJ includes extensions to support dynamic SQL directly. (See "Support for Dynamic SQL".)

Overview of SQLJ Components

This section introduces the main SQLJ components and the concept of SQLJ profiles. (Profiles are for ISO code generation only.)

SQLJ Translator and SQLJ Runtime

Oracle SQLJ consists of two major components:

In addition to the translator and runtime, there is a component known as the customizer that plays a role if you use ISO standard code generation. A customizer tailors SQLJ profiles for a particular database implementation and vendor-specific features and datatypes. By default, for ISO standard code, the Oracle SQLJ front end invokes an Oracle customizer to tailor your profiles for an Oracle database and Oracle-specific features and datatypes.

When you use the Oracle customizer during translation, your application will require the Oracle SQLJ runtime and an Oracle JDBC driver when it runs.

SQLJ Profiles (ISO Standard Code)

With ISO standard SQLJ code generation, SQLJ profiles are serialized Java resources (or, optionally, classes) generated by the SQLJ translator, which contain details about the embedded SQL operations in your SQLJ source code. The translator creates these profiles, then either serializes them and puts them into binary resource files, or puts them into .class files (according to your translator option settings).

Note:

By default, as of Oracle9i release 2, Oracle-specific code generation is used. In this case, the translator generates Oracle JDBC calls directly, and details of your embedded SQL operations are embodied in the JDBC calls. There are no profiles. See "Oracle-Specific Code Generation (No Profiles)".

Overview of Profiles

SQLJ profiles are used in ISO standard code in implementing the embedded SQL operations in your SQLJ executable statements. Profiles contain information about your SQL operations and the types and modes of data being accessed. A profile consists of a collection of entries, where each entry maps to one SQL operation. Each entry fully specifies the corresponding SQL operation, describing each of the parameters used in executing this instruction.

For ISO code generation, SQLJ generates a profile for each connection context class in your application, where, typically, each connection context class corresponds to a particular set of SQL entities you use in your database operations. (There is one default connection context class, and you can declare additional classes.) The ISO SQLJ standard requires that the profiles be of standard format and content. Therefore, for your application to use vendor-specific extended features, your profiles must be customized. By default, this occurs automatically, with your profiles being customized to use Oracle-specific extended features.

Profile customization allows vendors to add value in two ways:

For example, you must customize your profile to use Oracle objects in your SQLJ application.

Notes:
  • By default, SQLJ profile file names end in the .ser extension, but this does not mean that all .ser files are profiles. Other serialized objects can use that extension, and a SQLJ program unit can use serialized objects other than its profiles. (Optionally, profiles can be converted to .class files instead of .ser files.)
  • A SQLJ profile is not produced if there are no SQLJ executable statements in the source code.

Binary Portability

SQLJ-generated profile files support binary portability. That is, you can port them as is and use them with other kinds of databases or in other environments if you have not employed vendor-specific datatypes or features. This is true of generated .class files as well.

Overview of Oracle Extensions to the SQLJ Standard

Oracle9i SQLJ supports the ISO SQLJ specification. Because the ISO SQLJ standard is a superset of the ANSI SQLJ standard, it requires a JDK 1.2 or later environment that complies with J2EE. The ANSI SQLJ standard requires only JDK 1.1.x. The Oracle SQLJ translator accepts a broader range of SQL syntax than the ANSI SQLJ standard specifies.

The ANSI standard addresses only the SQL92 dialect of SQL, but allows extension beyond that. Oracle SQLJ supports the Oracle SQL dialect, which is a superset of SQL92. If you need to create SQLJ programs that work with other DBMS vendors, avoid using SQL syntax and SQL types that are not in the standard and, therefore, may not be supported in other environments. (On your product CD, the directory [Oracle_Home]/sqlj/demo/components includes a semantics-checker that you can use to verify that your SQLJ statements contain only standard SQL.)

For general information about Oracle SQLJ extensions, see Chapter 5, "Type Support", and Chapter 6, "Objects, Collections, and OPAQUE Types".

Oracle SQLJ Type Extensions

Oracle SQLJ supports the Java types listed below as extensions to the SQLJ standard. Do not use these or other types if you may want to use your code in other environments. To ensure that your application is portable, use the Oracle SQLJ -warn=portable flag. See "Translator Warnings (-warn)".

Using any of the following extensions requires Oracle-specific code generation or Oracle customization during translation, as well as the Oracle SQLJ runtime and an Oracle JDBC driver when your application runs.

Oracle SQLJ Functionality Extensions

Oracle SQLJ also supports the following extended functionality:

Basic Translation Steps and Runtime Processing

This section introduces the following:

For more detailed information about the translation steps, see "Internal Translator Operations".

SQLJ source code contains a mixture of standard Java source together with SQLJ class declarations and SQLJ executable statements containing embedded SQL operations.

SQLJ source files have the .sqlj file name extension. The file name must be a legal Java identifier. If the source file declares a public class (maximum of one), then the file name must match the name of this class. If the source file does not declare a public class, then the file name should match the first defined class.

SQLJ Translation Steps

After you have written your .sqlj file, you must run SQLJ to process the files. (For coding the .sqlj file, basic SQLJ programming features and key considerations are discussed in Chapter 3 and Chapter 4.) The following example, for the source file Foo.sqlj whose first public class is Foo, shows SQLJ being run in its simplest form, with no command-line options:

sqlj Foo.sqlj

What this command actually runs is a front-end script or utility (depending on the platform) that reads the command line, invokes a Java virtual machine (JVM), and passes arguments to it. The JVM invokes the SQLJ translator and acts as a front end.

This document refers to running the front end as "running SQLJ" and to its command line as the "SQLJ command line". For information about command-line syntax, see "Command-Line Syntax and Operations".

From this point the following sequence of events occurs (presuming each step completes without fatal error). See "Internal Translator Operations" for more detailed information.

  1. The JVM invokes the SQLJ translator.
  2. The translator parses the SQLJ and Java code in the .sqlj file, checking for proper SQLJ syntax and looking for type mismatches between your declared SQL datatypes and corresponding Java host variables. (Host variables are local Java variables used as input or output parameters in your SQL operations. "Java Host Expressions, Context Expressions, and Result Expressions" describes them.)
  3. Depending on SQLJ option settings, the translator invokes the online semantics-checker, the offline parser, neither, or both. This is to verify syntax of embedded SQL and PL/SQL statements and, for online checking, to check the use of database elements in your code against an appropriate database schema. Even when neither is specified, some basic level of checking is performed.

    When online checking is specified, SQLJ will connect to a specified database schema to verify that the database supports all the database tables, stored procedures, and SQL syntax that the application uses, and that the host variable types in the SQLJ application are compatible with datatypes of corresponding database columns.

  4. For Oracle-specific SQLJ code generation (the default -codegen=oracle), SQL operations are converted directly into Oracle JDBC calls, and no profiles are produced. See "Oracle-Specific Code Generation (No Profiles)".

    For ISO standard code generation (-codegen=iso), the translator processes your SQLJ source code, converts SQL operations to SQLJ runtime calls, and generates Java output code and one or more SQLJ profiles. A separate profile is generated for each connection context class in your source code, where a different connection context class is typically used for each interrelated set of SQL entities that you use in your operations.

    Generated Java code is put into a .java output file containing the following:

    • any class definitions and Java code from your .sqlj source file
    • class definitions created as a result of your SQLJ iterator and connection context declarations

      See "Overview of SQLJ Declarations".

    • a class definition for a specialized class (known as the profile-keys class) that SQLJ generates and uses in conjunction with your profiles (for ISO standard SQLJ code generation only)
    • calls to Oracle JDBC (for Oracle-specific code generation) or to the SQLJ runtime (for ISO standard code generation) to implement the actions of your embedded SQL operations

    Generated profiles (for ISO standard code generation only) contain information about all the embedded SQL statements in your SQLJ source code, such as actions to take, datatypes being manipulated, and tables being accessed. When your application is run, the SQLJ runtime accesses the profiles to retrieve your SQL operations and passes them to the JDBC driver.

    By default, profiles (if applicable) are put into .ser serialized resource files, but SQLJ can optionally convert the .ser files to .class files as part of the translation.

  5. The JVM invokes the Java compiler, which is usually, but not necessarily, the standard javac provided with the Sun Microsystems JDK.
  6. The compiler compiles the Java source file generated in step 4 and produces Java .class files as appropriate. This will include a .class file for each class you defined, a .class file for each of your SQLJ declarations, and a .class file for the profile-keys class (for ISO code generation).
  7. For ISO standard SQLJ code generation, the JVM invokes the Oracle SQLJ customizer or other specified customizer to customize the profiles generated in step 4.
General SQLJ Notes

Consider the following when translating and running SQLJ applications:

Summary of Translator Input and Output

This section summarizes what the SQLJ translator takes as input, what it produces as output, and where it places its output.

Note:

This discussion mentions iterator class and connection context class declarations. Iterators are similar to JDBC result sets; connection contexts are used for database connections. For more information about these class declarations, see "Overview of SQLJ Declarations".

Translator Input

In its most basic operation, the SQLJ translator takes one or more .sqlj source files as input in its command line. The name of your main .sqlj file is based on the public class it defines, if any, or else on the first class it defines. Each public class you define must be in its own .sqlj file.

If your main .sqlj file defines class MyClass, then the source file name must be:

MyClass.sqlj

This must also be the file name if there are no public class definitions but MyClass is the first class defined.

When you run SQLJ, you can also specify numerous SQLJ options in the command line or properties files.

For more information about SQLJ input, including additional types of files you can specify in the command line, see "Translator Command Line and Properties Files".

Translator Output

The translation step produces a Java source file for each .sqlj file in your application, and, for ISO standard code generation, at least one application profile (presuming your source code uses SQLJ executable statements).

SQLJ generates source files and profiles as follows:

The compilation step compiles the Java source file into multiple class files. There is one .class file for each class you define in your .sqlj source file (minimum of one), and, for ISO code, one for a class known as the profile-keys class that the translator generates and uses with the profiles to implement your SQL operations (presuming your source code uses SQLJ executable statements). Additional .class files are produced if you declared any SQLJ iterators or connection contexts. (See "Overview of SQLJ Declarations".) Also, separate .class files will be produced for any inner classes or anonymous classes in your code.

For Oracle-specific code generation (the default), no profiles or profile-keys class are produced. For information about Oracle-specific code generation, see "Oracle-Specific Code Generation (No Profiles)".

The .class files are named as follows:

The customization step alters the profiles but produces no additional output.

Note:

It is not necessary to reference SQLJ profiles or the profile-keys class directly. This is all handled automatically.

Output File Locations

By default, SQLJ places generated .java files in the same directory as your .sqlj file. You can specify a different .java file location, however, using the SQLJ -dir option.

By default, SQLJ places generated .class and .ser files (if any) in the same directory as the generated .java files. You can specify a different .class and .ser file location, however, using the SQLJ -d option. This option setting is passed to the Java compiler so that .class files and .ser files will be in the same location.

For either the -d or -dir option, you must specify a directory that already exists. For more information about these options, see "Options for Output Files and Directories".

SQLJ Runtime Processing

This section discusses runtime processing during program execution, considering both Oracle-specific code generation and ISO standard SQLJ code generation.

Processing for Oracle-Specific Generated Code

When you translate with the default setting -codegen=oracle, your program at runtime will execute the following:

For general information about Oracle-specific code generation, see "Oracle-Specific Code Generation (No Profiles)".

Processing for ISO Standard Generated Code

For ISO standard SQLJ applications, the SQLJ runtime reads the profiles and creates "connected profiles", which incorporate database connections. Then the following occurs each time the application must access the database:

  1. SQLJ-generated application code uses methods in a SQLJ-generated profile-keys class to access the connected profile and read the relevant SQL operations. There is a mapping between SQLJ executable statements in the application and SQL operations in the profile.
  2. The SQLJ-generated application code calls the SQLJ runtime, which reads the SQL operations from the profile.
  3. The SQLJ runtime calls the JDBC driver and passes the SQL operations to the driver.
  4. The SQLJ runtime passes any input parameters to the JDBC driver.
  5. The JDBC driver executes the SQL operations.
  6. If any data is to be returned, the database sends it to the JDBC driver, which sends it to the SQLJ runtime for use by your application.

    Note:

    Passing input parameters (step 4) can also be referred to as "binding input parameters" or "binding host expressions". The terms host variables, host expressions, bind variables, and bind expressions are all used to describe Java variables or expressions that are used as input or output for SQL operations.

JDBC Versus SQLJ Sample Code

This section presents a side-by-side comparison of two versions of the same sample code--one version written in JDBC and the other in SQLJ. The objective of this section is to point out the differences in coding requirements between SQLJ and JDBC.

The particulars of SQLJ statements and features used here are described later in this manual, but this example is still useful here to give you a general idea in comparing and contrasting SQLJ and JDBC. You can look at it again when you are more familiar with SQLJ concepts and features.

In the sample, two methods are defined: getEmployeeAddress(), which selects from a table and returns an employee's address based on the employee's number, and updateAddress(), which takes the retrieved address, calls a stored procedure, and returns the updated address to the database.

In both versions of the sample code, the following assumptions are made:

JDBC Version of the Sample Code

Following is the JDBC version of the sample code, which defines methods to retrieve an employee's address from the database, update the address, and return it to the database. Note that the to-do items in the comment lines indicate where you might want to add additional code to increase the usefulness of the code sample.

import java.sql.*;
import oracle.jdbc.*;

/**
  This is what we have to do in JDBC
  **/
public class SimpleDemoJDBC                                  // line 7
{

//TO DO: make a main that calls this

  public Address getEmployeeAddress(int empno, Connection conn)
    throws SQLException                                     // line 13
  {
    Address addr;
    PreparedStatement pstmt =                               // line 16
      conn.prepareStatement("SELECT office_addr FROM employees" + 
       " WHERE empnumber = ?");
    pstmt.setInt(1, empno);
    OracleResultSet rs = (OracleResultSet)pstmt.executeQuery();
    rs.next();                                              // line 21
     //TO DO: what if false (result set contains no data)?
    addr = (Address)rs.getORAData(1, Address.getORADataFactory());
    //TO DO: what if additional rows? 
    rs.close();                                             // line 25
    pstmt.close();
    return addr;                                            // line 27
  }
  public Address updateAddress(Address addr, Connection conn)
    throws SQLException                                     // line 30
                                                           
  {
    OracleCallableStatement cstmt = (OracleCallableStatement)
      conn.prepareCall("{ ? = call UPDATE_ADDRESS(?) }");   //line 34
    cstmt.registerOutParameter(1, Address._SQL_TYPECODE, Address._SQL_NAME);
                                                            // line 36
    if (addr == null) {
      cstmt.setNull(2, Address._SQL_TYPECODE, Address._SQL_NAME);
    } else {
      cstmt.setORAData(2, addr);
    } 
    
    cstmt.executeUpdate();                                  // line 43
    addr = (Address)cstmt.getORAData(1, Address.getORADataFactory());
    cstmt.close();                                          // line 45
    return addr;
  }
}
Line 12:

In the getEmployeeAddress() method definition, you must pass the connection object to the method definition explicitly.

Lines 16-20:

Prepare a statement that selects an employee's address from the EMPLOYEES table, based on the employee number. The employee number is represented by a marker variable, which is set with the setInt() method. Note that because the prepared statement does not recognize "INTO" syntax, you must provide your own code to populate the address (addr) variable. Because the prepared statement is returning a custom object, cast the output to an Oracle result set.

Lines 21-23:

Because the Oracle result set contains a custom object of type Address, use the getORAData() method to retrieve it. The Address class can be created by JPublisher. The getORAData() method requires a "factory" object that it can use to create additional custom objects (additional Address objects in this case) as it retrieves the data to populate them. Use the static factory method Address.getORADataFactory() to materialize an Address factory object for the getORAData() method to use.

Because getORAData() returns a Datum, cast the output to an Address object.

Note that the routine assumes a one-row result set. The to-do items in the comment statements indicate that you must write additional code for the cases where the result set contains either no rows or more than one row.

Lines 25-27:

Close the result set and prepared statement objects, then return the addr variable.

Line 29:

In the updateAddress() definition, you must pass the connection object and the Address object explicitly.

The updateAddress() method passes an address object (Address) to the database for update, then fetches it back. The actual updating of the address is performed by the stored function UPDATE_ADDRESS(). (The code for this function is not provided in this example.)

Line 33-43:

Prepare an Oracle callable statement that takes an address object (Address) and passes it to the UPDATE_ADDRESS() stored procedure. To register an object as an output parameter, you must know the SQL type code and SQL type name of the object.

Before passing the address object (addr) as an input parameter, the program must determine whether addr has a value or is null. Depending on the value of addr, the program calls different setter methods. If addr is null, the program calls setNull(); if addr has a value, the program calls setORAData().

Line 44:

Fetch the return result addr. Because the Oracle callable statement returns a custom object of type Address, use the getORAData() method to retrieve it. The Address class can be created by JPublisher. The getORAData() method requires you to use the factory method Address.getORADataFactory to materialize an instance of an Address object. Because getORAData() returns a Datum object, cast the output to an Address object.

Lines 45, 46:

Close the Oracle callable statement, then return the addr variable.

Coding Requirements of the JDBC Version

Note the following coding requirements for the JDBC version of the sample code:

Maintaining JDBC Programs

JDBC programs are potentially expensive to maintain. For example, in the above code sample, if you add another WHERE clause, then you must change the SELECT string. If you append another host variable, then you must increment the index of the other host variables by one. A simple change to one line in a JDBC program might require changes in several other areas of the program.

SQLJ Version of the Sample Code

Following is the SQLJ version of the sample code that defines methods to retrieve an employee's address from the database, update the address, and return it to the database.

import java.sql.*;

/**
  This is what we have to do in SQLJ
  **/
public class SimpleDemoSQLJ                                  // line 6
{
  //TO DO: make a main that calls this

  public Address getEmployeeAddress(int empno)              // line 10
    throws SQLException
  {
    Address addr;                                           // line 13
    #sql { SELECT office_addr INTO :addr FROM employees
           WHERE empnumber = :empno };
    return addr;
  }
                                                            // line 18
  public Address updateAddress(Address addr)
    throws SQLException
  {
    #sql addr = { VALUES(UPDATE_ADDRESS(:addr)) };          // line 22
    return addr;
  }
}
Line 10:

The getEmployeeAddress() method does not require an explicit connection object. SQLJ can use a default connection context instance, which would have been initialized previously somewhere in the application.

Lines 13-15:

The getEmployeeAddress() method retrieves an employee address according to employee number. Use standard SQLJ SELECT INTO syntax to select an employee's address from the employee table if the employee number matches the one (empno) passed in to getEmployeeAddress(). This requires a declaration of the Address object (addr) that will receive the data. The empno and addr variables are used as input host variables.

Line 16:

The getEmployeeAddress() method returns the addr object.

Line 19:

The updateAddress() method also uses the default connection context instance.

Lines 19-22:

The address is passed to the updateAddress() method, which passes it to the database. The database updates it and passes it back. The actual updating of the address is performed by the UPDATE_ADDRESS() stored function. (The code for this function is not shown here.) Use standard SQLJ function-call syntax to receive the address object (addr) output by UPDATE_ADDRESS().

Line 23:

The updateAddress() method returns the addr object.

Coding Requirements of the SQLJ Version

Note the following coding requirements (and lack of requirements) for the SQLJ version of the sample code:

Alternative Deployment Scenarios

Although this manual mainly discusses writing for client-side SQLJ applications, you may find it useful to run SQLJ code in the following scenarios:

Running SQLJ in Applets

Because the SQLJ runtime is pure Java, you can use SQLJ source code in applets as well as applications. There are, however, a few considerations, as discussed below.

For applet issues that apply more generally to the Oracle JDBC drivers, see the Oracle9i JDBC Developer's Guide and Reference, which includes discussion of firewalls and security issues as well.

General Development and Deployment Considerations

The following general considerations apply to the use of Oracle SQLJ applets.

General End User Considerations

When end users run your SQLJ applet, classes in their classpath may conflict with classes that are downloaded with the applet.

Oracle, therefore, recommends that end users clear their classpath before running the applet.

Java Environment and the Java Plug-in

Here are some additional considerations regarding the Java environment and use of Oracle-specific features.

The preceding issues can be summarized as follows, focusing on users with Internet Explorer and Netscape browsers:

Introduction to SQLJ in the Server

In addition to its use in client applications, SQLJ code can run within a target Oracle9i database in stored procedures, stored functions, or triggers. Server-side access occurs through an Oracle JDBC driver that runs inside the server itself. Additionally, the Oracle9i database has an embedded SQLJ translator so that SQLJ source files for server-side use can optionally be translated directly in the server.

The two main areas to consider, which Chapter 11, "SQLJ in the Server", discusses in detail, are the following:

Using SQLJ with Oracle9i Lite

You can use SQLJ on top of Oracle9i Lite. This section provides an overview of this functionality. For more information, refer to the Oracle9i Lite Java Developer's Guide.

Overview of Oracle9i Lite and Java Support

Oracle9i Lite is a lightweight database that offers flexibility and versatility that larger databases cannot. It requires only 350K to 750K of memory for full functionality, natively synchronizes with the Palm Computing platform, and can run on Windows NT (3.51 or higher), Windows 95, and Windows 98. It offers an embedded environment that requires no background or server processes.

Oracle9i Lite is compatible with Oracle9i, Oracle8i, Oracle8, and Oracle7. It provides comprehensive support for Java, including JDBC, SQLJ, and Java stored procedures. There are two alternatives for access to Oracle9i Lite from Java programs, as follows:

There is interoperability between Oracle9i Lite JDBC and JAC, with JAC supporting all types that JDBC supports, and JDBC supporting JAC types that meet certain requirements.

Requirements to Run Java on Oracle9i Lite

Note the following requirements if you intend to run a Java program on top of Oracle9i Lite:

Support for Oracle Extensions

Oracle9i Lite 4.0.x and higher includes an Oracle-specific JDBC driver and Oracle-specific SQLJ runtime classes (including the Oracle semantics-checkers and customizer), allowing use of Oracle-specific features and type extensions.

Alternative Development Scenarios

The discussion in this book assumes that you are coding manually in a UNIX environment for English-language deployment. However, you can use SQLJ on other platforms and with IDEs. There is also globalization support for deployment to other languages. This section introduces these topics:

SQLJ Globalization Support

Oracle SQLJ support for native languages and character encodings is based on Java built-in globalization support capabilities.

The standard user.language and file.encoding properties of the JVM determine appropriate language and encoding for translator and runtime messages. The SQLJ -encoding option determines encoding for interpreting and generating source files during translation.

For information, see "Globalization Support in the Translator and Runtime".

SQLJ in Oracle9i JDeveloper and Other IDEs

Oracle SQLJ includes a programmatic API so that it can be embedded in integrated development environments (IDEs) such as Oracle9i JDeveloper. The IDE takes on a role similar to that of the front-end sqlj script, invoking the translator, semantics-checker, compiler, and customizer (as applicable).

JDeveloper is a Windows NT-based visual development environment for Java programming. The JDeveloper Suite enables developers to build multitier, scalable Internet applications using Java across the Oracle Internet Platform. The core product of the suite--the JDeveloper Integrated Development Environment--excels in creating, debugging, and deploying component-based applications.

The Oracle JDBC OCI and Thin drivers are included with JDeveloper, as well as drivers to access Oracle9i Lite.

JDeveloper's compilation functionality includes an integrated Oracle SQLJ translator so that your SQLJ application is translated automatically as it is compiled.

Information about JDeveloper is available at the following URL:

http://otn.oracle.com/products/jdev/content.html

Windows Considerations

Note the following if you are using a Windows platform instead of a UNIX environment:

Refer to the Windows platform README file for additional information.

Go to previous page Go to next page
Oracle
Copyright © 1999, 2002 Oracle Corporation.
All Rights Reserved.
Go To Documentation Library
Home		 Go To Product List
Book List		 Go To Table Of Contents
Contents		 Go To Index
Index
Master Index
Feedback