|Oracle8i SQLJ Developer's Guide and Reference
The discussion in this book is mostly from the perspective of writing for client-side SQLJ applications, but you may find it useful to run SQLJ code in the following scenarios:
The SQLJ runtime is pure Java, so you can use SQLJ source code in applets as well as applications. There are, however, a few considerations:
As well as the following if you used Oracle customization:
These are all included in the file
runtime.zip, which comes with your Oracle SQLJ installation.
The total size of the downloaded SQLJ packages will be approximately 150K-250K (uncompressed) or 40K-70K (compressed), depending on whether your applet requires Oracle customization and/or internationalized messages.
.serextension, which is the extension used by the SQLJ serialized object files used for profiles. However, Oracle SQLJ provides the
-ser2classoption to convert
.classfiles. See "Conversion of .ser File to .class File (-ser2class)" for more information.
Sun Microsystems offers such a plug-in. For information, refer to the following Web site:
For additional information, please see the SQLJ
README file and examine the sample applet (not included in this document) in the SQLJ
demo directory. These will explain any additional steps to take.
For applet issues that apply more generally to the Oracle JDBC drivers, see the Oracle8i JDBC Developer's Guide and Reference. This includes discussion of firewalls and security issues as well.
In addition to its use in client applications, SQLJ code can run in the Oracle8i Server in stored procedures, stored functions, triggers, Enterprise JavaBeans, or CORBA objects. Server-side access is through the Oracle JDBC server-side driver. There is also an embedded SQLJ translator in the Oracle8i Server so that SQLJ source files for server-side use can optionally be translated directly in the server.
The two main areas to consider, which are discussed in detail in Chapter 11, "SQLJ in the Server", are:
In creating a SQLJ application for use against the Oracle8i Server, there is very little difference between coding for server-side use as opposed to client-side use. What issues do exist are due to general JDBC characteristics as opposed to SQLJ-specific characteristics. The main differences involve connections:
Additionally, the JDBC server-side driver does not support auto-commit.
You can translate and compile your code either on a client or in the server. If you do this on a client, you can then load the class and resource files into the server from your client machine, either pushing them from the client using the Oracle
loadjava utility or pulling them in from the server using SQL commands. (It is convenient to have them all in a single
.jar file first.)
Alternatively, you can translate and load in one step using the embedded server-side SQLJ translator. If you load a SQLJ source file instead of class or resource files, then you can specify that translation and compilation be done automatically. In general,
loadjava or SQL commands can be used for class and resource files or for source files. From a user perspective
.sqlj files are treated the same as
.java files, with translation taking place implicitly if requested.
See "Loading SQLJ Source and Translating in the Server" for information about using the embedded server-side translator.
You can use SQLJ on top of an Oracle Lite database. This section provides a brief overview of this functionality. For more information, refer to the Oracle Lite Java Developer's Guide.
Oracle 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.
Oracle Lite is compatible with Oracle8i, previous versions of Oracle8, and Oracle7. It provides comprehensive support for Java, including JDBC, SQLJ, and Java stored procedures. There are two alternatives for access to the Oracle Lite database from Java programs:
This is intended for Java applications that use the relational data model, allowing them direct communication with the object-relational database engine.
Use the relational data model if your program has to access data that is already in SQL format, must run on top of other relational database systems, or uses very complex queries.
This is intended for Java applications that use either the Java object model or the Oracle Lite object model, allowing them to access persistent information stored in the Oracle Lite database without having to map between the object model and the relational model. Use of JAC also requires a persistent Java proxy class to model the Oracle Lite schema. This can be generated by Oracle Lite tools.
Use the object model if you want your program to have a smaller footprint and run faster and you do not require the full capability of the SQL language.
There is interoperability between Oracle Lite JDBC and JAC, with JAC supporting all types that JDBC supports, and JDBC supporting JAC types that meet certain requirements.
Note the following requirements if you intend to run a Java program on top of an Oracle Lite database:
The JREs supplied with JDK 1.1, Oracle JDeveloper, and Symantec Visual Cafe support JNI.
The JDBC driver implemented with Oracle Lite versions 3.6 and prior supports standard SQL92 types only, so Oracle-specific functionality cannot be used on top of these versions. Therefore, you cannot use Oracle type extensions such as
ROWID, and user-defined object and collection types.
Beginning with version 4.0, however, Oracle Lite will include 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.