Core JDBC Functionality

The core functionality of all Oracle JDBC drivers is the same. They support the same feature set, syntax, programming interfaces, and Oracle extensions.

All Oracle JDBC drivers are supported by the oracle.jdbc.OracleDriver class.

JDBC OCI Driver

Oracle JDBC OCI driver accesses the database by calling the OCI directly from Java, providing the highest compatibility with the different Oracle Database versions. These drivers support installed Oracle Net adapters, including interprocess communication (IPC), named pipes, TCP/IP, and IPX/SPX.

The use of native methods to call C entry points makes the OCI driver dependent on the Oracle platform, requiring an Oracle client installation that includes Oracle Net. Therefore it is not suitable for applets.

Connection strings for the OCI driver are of the following form, where tns is an optional TNS alias or full TNS specification:

jdbc:oracle:oci:@<tns>

JDBC Thin Driver

Oracle JDBC Thin driver is a platform-independent, pure Java implementation that uses Java sockets to connect directly to Oracle Database from any Oracle or non-Oracle client. It can be downloaded into a browser simultaneously with the Java applet being run.

The JDBC Thin driver supports only TCP/IP protocol and requires a TNS listener to be listening on TCP/IP sockets from the database server. When the JDBC Thin driver is used with an applet, the client browser must have the capability to support Java sockets.

Connection strings for the JDBC Thin driver are typically of the following form:

jdbc:oracle:thin:@host:port/servicename

In Oracle Database 12c Release 2 (12.2), connection strings using SIDs are deprecated, but are still supported for backward compatibility:

jdbc:oracle:thin:@host:port:sid

JDBC Server-Side Thin Driver

Oracle JDBC server-side Thin driver offers the same functionality as the client-side JDBC Thin driver, but runs inside the database and accesses a remote server. This is useful in accessing one Oracle Database instance from inside another, such as from a Java stored procedure.

Connection strings for the server-side Thin driver are the same as for the client-side Thin driver.

JDBC Server-Side Internal Driver

Oracle JDBC server-side internal driver provides support for any Java code that runs inside the target Oracle Database instance where the SQL operations are to be performed. The server-side internal driver enables Oracle Java virtual machine (JVM) to communicate directly with the SQL engine. This driver is the default JDBC driver for SQLJ code running as a stored procedure, stored function, or trigger in Oracle Database 12c Release 2 (12.2).

Connection strings for the server-side internal driver are of the following form:

jdbc:oracle:kprb:

If your SQLJ code uses the default connection context, then SQLJ automatically uses this driver for code running in Oracle JVM.

Use SQLJ option settings, either on the command line or in a properties file, to choose the driver manager class and specify a driver for translation.

Use the SQLJ -driver option to choose any driver manager class other than OracleDriver, which is the default.

Specify the particular JDBC driver to choose, such as JDBC Thin or JDBC OCI for Oracle Database, as part of the connection URL you specify in the SQLJ -url option.

You will typically, but not necessarily, use the same driver that you use in your source code for the run-time connection.

To connect to the database at run time, you must register one or more drivers that will understand the URLs you specify for any of your connection instances, whether they are instances of the sqlj.runtime.ref.DefaultContext class or of any connection context classes that you declare.

If you are using an Oracle JDBC driver and create a default connection using the Oracle.connect() method, then SQLJ handles this automatically. The Oracle.connect() method registers the oracle.jdbc.OracleDriver class.

If you are using an Oracle JDBC driver, but do not use Oracle.connect(), then you must manually register the OracleDriver class, as follows:

DriverManager.registerDriver(new oracle.jdbc.OracleDriver());

If you are not using an Oracle JDBC driver, then you must register some appropriate driver class, as follows:

DriverManager.registerDriver(new mydriver.jdbc.driver.MyDriver());

In any case, you must also set your connection URL, user name, and password.

This section discusses scenarios where you will use connection instances of only the DefaultContext class.

This is typical if you are using a single connection, or multiple connections that use SQL entities with the same names and data types.

Single Connection

For a single connection, use one instance of the DefaultContext class specifying the database URL, user name, and password, when you construct your DefaultContext object.

You can use the connect() method of the oracle.sqlj.runtime.Oracle class to accomplish this. Calling this method automatically initializes the default connection context instance. This method has several signatures, including ones that allow you to specify user name, password, and URL, either directly or using a properties file. In the following example, the properties file connect.properties is used:

Oracle.connect(MyClass.class, "connect.properties");

If you use connect.properties, then you must edit it appropriately and package it with your application. In this example, you must also import the oracle.sqlj.runtime.Oracle class.

Alternatively, you can specify user name, password, and URL directly:

Oracle.connect("jdbc:oracle:thin:@localhost:5221/myservice", "HR", "hr");

In this example, the connection will use the JDBC Thin driver to connect the HR user with the password, hr, to a database on the computer, localhost, through port 5221, where myservice is the name of the database service for the connection.

Either of these examples creates a special static instance of the DefaultContext class and installs it as your default connection. It is not necessary to do anything with this DefaultContext instance directly.

Once you have completed these steps, you do not need to specify the connection for any of the SQLJ executable statements in your application, if you want them all to use the default connection.

Note that in using a JDBC Thin driver, the URL must include the host name, port number, and service name (or SID, which is deprecated in Oracle Database 12c Release 2 (12.2)), as in the preceding example. Also, the database must have a listener running at the specified port. In using the JDBC OCI driver, no service name (or SID) is required if you intend to use the default account of the client, as will be the case in examples in this document. Alternatively, you can use name-value pairs.

The following URL will connect to the default account of the client:

jdbc:oracle:oci:@

Multiple Connections

For multiple connections, you can create and use additional instances of the DefaultContext class, while optionally still using the default connection.

You can use the Oracle.getConnection() method to instantiate DefaultContext, as in the following examples.

First, consider a case where you want most statements to use the default connection, but other statements to use a different connection. You must create one additional instance of DefaultContext:

DefaultContext ctx = Oracle.getConnection (
   "jdbc:oracle:thin:@localhost2:5221/myservice2", "bill", "lion");

When you want to use the default connection, it is not necessary to specify a connection context:

#sql { SQL operation };

This is actually a shortcut for the following:

#sql [DefaultContext.getDefaultContext()] { SQL operation };

When you want to use the additional connection, specify ctx as the connection:

#sql [ctx] { SQL operation };

Next, consider situations where you want to use multiple connections, where each of them is a named DefaultContext instance. This enables you to switch your connection back and forth.

The following statements establish multiple connections to the same schema (in case you want to use multiple Oracle Database sessions or transactions, for example). Instantiate the DefaultContext class for each connection you will need:

DefaultContext ctx1 = Oracle.getConnection
   ("jdbc:oracle:thin:@localhost1:5221/myservice1", "HR", "hr");
DefaultContext ctx2 = Oracle.getConnection
   ("jdbc:oracle:thin:@localhost1:5221/myservice1", "HR", "hr");

This creates two connection context instances that would use the same schema, connecting to HR/hr using service myservice1 on the computer localhost1, using Oracle JDBC Thin driver.

Now, consider a case where you would want multiple connections to different schemas. Again, instantiate the DefaultContext class for each connection you will need:

DefaultContext ctx1 = Oracle.getConnection
   ("jdbc:oracle:thin:@localhost1:5221/myservice1", "HR", "hr");
DefaultContext ctx2 = Oracle.getConnection
   ("jdbc:oracle:thin:@localhost2:5221/myservice2", "bill", "lion");

This creates two connection context instances that use Oracle JDBC Thin driver but use different schemas. The ctx1 object connects to HR/hr using service myservice1 on the computer localhost1, while the ctx2 object connects to bill/lion using service myservice2 on the computer localhost2.

There are two ways to switch back and forth between these connections for the SQLJ executable statements in your application:

• If you switch back and forth frequently, then you can specify the connection for each statement in your application:

  #sql [ctx1] { SQL operation };
  ...
  #sql [ctx2] { SQL operation };
  

  Note:

  Include the square brackets around the connection context instance name; they are part of the syntax.

• If you use either of the connections several times in a row within your code flow, then you can periodically use the static setDefaultContext() method of the DefaultContext class to reset the default connection. This method initializes the default connection context instance. This way, you can avoid specifying connections in your SQLJ statements.

  DefaultContext.setDefaultContext(ctx1);
  #sql { SQL operation };   // These three statements all use ctx1
  #sql { SQL operation };
  #sql { SQL operation };
  ...
  DefaultContext.setDefaultContext(ctx2);
  #sql { SQL operation };   // These three statements all use ctx2
  #sql { SQL operation };
  #sql { SQL operation };
  

  Note:

  Because the preceding statements do not specify connection contexts, at translation time they will all be checked against the default connection context.

It is advisable to close your connection context instances when you are done, preferably in a finally clause of a try block (in case your application terminates with an exception).

The DefaultContext class, as well as any connection context classes that you declare, includes a close() method. Calling this method closes the SQLJ connection context instance and, by default, also closes the underlying JDBC connection instance and the physical connection.

In addition, the oracle.sqlj.runtime.Oracle class has a static close() method to close the default connection only. In the following example, presume ctx is an instance of any connection context class:

...
finally
{
   ctx.close();
}
...

Alternatively, if the finally clause is not within a try block in case a SQL exception is encountered:

...
finally
{
   try { ctx.close(); } catch(SQLException ex) {...}
}
...

Or, to close the default connection, the Oracle class also provides a close() method:

...
finally
{
   Oracle.close();
}
...

Always commit or roll back any pending changes before closing the connection. Whether there would be an implicit COMMIT operation as the connection is closed is not specified in the JDBC standard and may vary from vendor to vendor. For Oracle, there is an implicit COMMIT when a connection is closed, and an implicit ROLLBACK when a connection is garbage-collected without being closed, but it is not advisable to rely on these mechanisms.

Signatures of the Oracle.connect() and Oracle.getConnection() Methods

Both the method have signatures that take the following parameter sets as input:

• URL (String), user name (String), password (String)

• URL (String), user name (String), password (String), auto-commit flag (boolean)

• URL (String), java.util.Properties object containing properties for the connection

• URL (String), java.util.Properties object, auto-commit flag (boolean)

• URL (String) fully specifying the connection, including user name and password

  The following is an example of the format of a URL string specifying user name (HR) and password (hr) when using Oracle JDBC drivers, in this case the JDBC Thin driver:

  "jdbc:oracle:thin:HR/hr@localhost:5221/myservice"
  

• URL (String), auto-commit flag (boolean)

• A java.lang.Class object for the class relative to which the properties file is loaded, name of properties file (String)

• A java.lang.Class object, name of properties file (String), auto-commit flag (boolean)

• A java.lang.Class object, name of properties file (String), user name (String), password (String)

• A java.lang.Class object, name of properties file (String), user name (String), password (String), auto-commit flag (boolean)

• JDBC connection object (Connection)

• SQLJ connection context object

These last two signatures inherit an existing database connection. When you inherit a connection, you will also inherit the auto-commit setting of that connection.

The auto-commit flag specifies whether SQL operations are automatically committed. For the Oracle.connect() and Oracle.getConnection() methods only, the default is false. If that is the setting you want, then you can use one of the signatures that does not take auto-commit as input. However, anytime you use a constructor to create an instance of a connection context class, including DefaultContext, you must specify the auto-commit setting. In the Oracle JDBC implementation, the default for the auto-commit flag is true.

Optional Oracle.close() Method Parameters

In using the Oracle.close() method to close the default connection, you have the option of specifying whether or not to close the underlying physical database connection. By default it is closed. This is relevant if you are sharing this physical connection between multiple connection objects, either SQLJ connection context instances or JDBC connection instances.

You can keep the underlying physical connection open as follows:

Oracle.close(ConnectionContext.KEEP_CONNECTION);

You can close the underlying physical connection (default behavior) as follows:

Oracle.close(ConnectionContext.CLOSE_CONNECTION);

KEEP_CONNECTION and CLOSE_CONNECTION are static constants of the ConnectionContext interface.

DefaultContext Methods

The following are the key methods of the DefaultContext class:

• getConnection()

  Gets the underlying JDBC connection object. This is useful if you want to have JDBC code in your application, which is one way to use dynamic SQL operations. You can also use the setAutoCommit() method of the underlying JDBC connection object to set the auto-commit flag for the connection.

• setDefaultContext()

  Sets the default connection your application uses. This is a static method and takes a DefaultContext instance as input. SQLJ executable statements that do not specify a connection context instance will use the default connection that you define using this method or the Oracle.connect() method.

• getDefaultContext()

  Returns the DefaultContext instance currently defined as the default connection for your application. This is a static method.

• close()

  Closes the connection context instance.

The getConnection() and close() methods are specified in the sqlj.runtime.ConnectionContext interface.

DefaultContext Constructors

It is typical to instantiate DefaultContext using the Oracle.connect() or Oracle.getConnection() method. However, if you want to create an instance directly, then there are five constructors for DefaultContext. The different input parameter sets for these constructors are:

• URL (String), user name (String), password (String), auto-commit (boolean)

• URL (String), java.util.Properties object, auto-commit (boolean)

• URL (String fully specifying connection and including user name and password), auto-commit setting (boolean)

  The following is an example of the format of a URL specifying user name and password when using Oracle JDBC drivers, in this case the JDBC Thin driver:

  "jdbc:oracle:thin:HR/hr@localhost:5221/myservice"
  

• JDBC connection object (Connection)

• SQLJ connection context object

The last two signatures inherit an existing database connection. When you inherit a connection, you will also inherit the auto-commit setting of that connection.

Following is an example of constructing a DefaultContext instance:

DefaultContext defctx = new DefaultContext
   ("jdbc:oracle:thin:@localhost:5221/myservice", "HR", "hr", false);

Notes About Connection Context Constructors:

Optional DefaultContext close() Method Parameters

When you close a connection context instance, you have the option of specifying whether or not to close the underlying physical connection. By default it is closed. This is relevant if you are sharing the physical connection between multiple connection objects, either SQLJ connection context instances or JDBC connection instances. The following examples presume a DefaultContext instance defctx.

To keep the underlying physical connection open, use the following:

defctx.close(ConnectionContext.KEEP_CONNECTION);

To close the underlying physical connection, which is the default behavior, use the following:

defctx.close(ConnectionContext.CLOSE_CONNECTION);

KEEP_CONNECTION and CLOSE_CONNECTION are static constants of the ConnectionContext interface.

If you want to use online semantics-checking during translation, then you must specify a database connection for SQLJ to use. These are referred to as exemplar schemas.

You can use different connections for translation and run time. In fact, it is often necessary or preferable to do so. It might be necessary if you are not developing the application in the same kind of environment that it will run in. But even if the run-time connection is available during translation, it might be preferable to create an account with a narrower set of resources so that your online checking will be tighter. This would be true if your application uses only a small subset of the SQL entities available in the run-time connection. Your online checking would be tighter and more meaningful if you create an exemplar schema consisting only of SQL entities that your application actually uses.

Use the SQLJ translator connection options, either on the command line or in a properties file, to specify a connection for translation.

The following examples show the use of the java.lang wrapper classes to handle NULL.

Example: Null Input Host Variable

In the following example, a Float object is used to pass a null value to the database:

int empno = 7499;
Float commission = null;

#sql { UPDATE employees SET commission_pct = :commission WHERE employee_id = :empno };

You cannot use the Java primitive type float to accomplish this.

Example: Null Iterator Rows

In the following example, a Double column type is used in an iterator to allow for the possibility of null data.

For each employee in the employee table whose salary is at least $50,000, the employee name (FIRST_NAME) and commission (COMMISSION_PCT) are selected into the iterator. Then each row is tested to determine if the COMMISSION_PCT field is, in fact, null. If so, then it is processed accordingly.

#sql iterator EmployeeIter (String first_name, Double commission);

EmployeeIter ei;
#sql ei = { SELECT first_name, commission_pct FROM employees WHERE salary >= 50000 };

while (ei.next())
{
   if (ei.commission_pct() == null) 
      System.out.println(ei.first_name() + " is not on commission.");
}
ei.close();
...

...WHERE :x IS NULL

Example: Exception Handling

This section discusses ways to process and interpret exceptions in your SQLJ application. During run time, exceptions may be raised from any of the following:

• SQLJ run time

• JDBC driver

• RDBMS

Printing Error Text

The example in the previous section showed how to catch SQL exceptions and output the error messages. Part of that code is as follows:

...
try {
...
} catch (SQLException e) { 
      System.err.println("Error running the example: " + e); 
}
...

This will print the error text from the SQLException object.

You can also retrieve error information using the getMessage(), getErrorCode(), and getSQLState() methods the SQLException class.

Printing the error text, as in this example, prints the error message with some additional text, such as SQLException.

Retrieving SQL States and Error Codes

The java.sql.SQLException class and subclasses include the getMessage(), getErrorCode(), and getSQLState() methods. Depending on where the exception or error originated and how they are implemented there, the following methods provide additional information:

• String getMessage()

  If the error originates in the SQLJ run time or JDBC driver, then this method returns the error message with no prefix. If the error originates in the RDBMS, then it returns the error message prefixed by the ORA number.

• int getErrorCode()

  If the error originates in the SQLJ run time, then this method returns no meaningful information. If the error originates in the JDBC driver or RDBMS, then it returns the five-digit ORA number as an integer.

• String getSQLState()

  If the error originates in the SQLJ run time, then this method returns a string with a five-digit code indicating the SQL state. If the error originates in the JDBC driver, then it returns no meaningful information. If the error originates in the RDBMS, then it returns the five-digit SQL state. Your application should have appropriate code to handle null values returned.

The following example prints the error message and also checks the SQL state:

...
try {
...
} catch (SQLException e) { 
      System.err.println("Error running the example: " + e); 
      String sqlState = e.getSQLState();
      System.err.println("SQL state = " + sqlState); 
}
...

For more specific error-checking, use any available and appropriate subclasses of the java.sql.SQLException class.

SQLJ provides the sqlj.runtime.NullException class, which is a subclass of java.sql.SQLException. You can use this exception in situations where a NULL might be returned into a Java primitive variable.

For batch-enabled environments, there is also the standard java.sql.BatchUpdateException subclass. Refer to "Error Conditions During Batch Execution" for further information.

When you use a subclass of SQLException, catch the subclass exception before catching SQLException, as in the following example:

...
try {
...
} catch (SQLNullException ne) {
     System.err.println("Null value encountered: " + ne); }
  catch (SQLException e) { 
     System.err.println("Error running the example: " + e); }
...

This is because a subclass exception can also be caught as a SQLException. If you catch SQLException first, then execution will not proceed to the part where you have coded special processing for the subclass exception.

There is typically no reason to change the auto-commit flag setting for an existing connection, but you can if you desire. You can do this by using the setAutoCommit() method of the underlying JDBC connection object.

You can retrieve the underlying JDBC connection object by using the getConnection() method of any SQLJ connection context instance, whether it is an instance of the DefaultContext class or of a connection context class that you declared.

You can accomplish these two steps at once, as follows:

ctx.getConnection().setAutoCommit(false);

or:

ctx.getConnection().setAutoCommit(true);

In these examples, ctx is a SQLJ connection context instance.

If you disable the auto-commit flag, then you must manually commit any data updates. To commit any changes that have been executed since the last COMMIT operation, use the SQLJ COMMIT statement, as follows:

#sql { COMMIT };

To roll back any changes that have been executed since the last COMMIT operation, use the SQLJ ROLLBACK statement, as follows:

#sql { ROLLBACK };

COMMIT and ROLLBACK operations do not affect open result sets and iterators. The result sets and iterators will still be open. Usually, all that is relevant to their content is the state of the database at the time of execution of the SELECT statements that populated them.

This also applies to UPDATE, INSERT, and DELETE statements that are executed after the SELECT statements. Execution of these statements does not affect the contents of open result sets and iterators.

Consider a situation where you SELECT, then UPDATE, and then COMMIT. A nonsensitive result set or iterator populated by the SELECT statement will be unaffected by the UPDATE and COMMIT.

As a further example, consider a situation where you UPDATE, then SELECT, and then ROLLBACK. A nonsensitive result set or iterator populated by the SELECT will still contain the updated data, regardless of the subsequent ROLLBACK.

The JDBC 3.0 specification added support for savepoints. A savepoint is a defined point in a transaction that you can roll back to, if desired, instead of rolling back the entire transaction. The savepoint is the point in the transaction where the SAVEPOINT statement appears.

In Oracle9i Database Release 2 (9.2), SQLJ first included Oracle-specific syntax to support savepoints. In Oracle Database 12c Release 2 (12.2), SQLJ adds support for ISO SQLJ standard savepoint syntax.

Support for ISO SQLJ Standard Savepoint Syntax

In ISO SQLJ standard syntax, use a string literal in a SAVEPOINT statement to designate a name for a savepoint. This can be done as follows:

#sql { SAVEPOINT savepoint1 };

If you want to roll back changes to that savepoint, then you can refer to the specified name later in a ROLLBACK TO statement, as follows:

#sql { ROLLBACK TO savepoint1 };

Use a RELEASE SAVEPOINT statement if you no longer need the savepoint:

#sql { RELEASE SAVEPOINT savepoint1 };

Savepoints are saved in the SQLJ execution context, which has methods that parallel the functionality of these three statements.

Because any COMMIT operation ends the transaction, this also releases all savepoints of the transaction.

Oracle SQLJ Savepoint Syntax

In addition to the ISO SQLJ standard syntax, the following Oracle-specific syntax for savepoints is supported. Note that the Oracle syntax uses string host expressions, rather than string literals.

You can set a savepoint as follows:

#sql { SET SAVEPOINT :savepoint };

The host expression, savepoint in this example, is a variable that specifies the name of the savepoint as a Java String.

You can roll back to a savepoint as follows:

#sql { ROLLBACK TO :savepoint };

To release a savepoint, use the following SQLJ statement:

#sql { RELEASE :savepoint };

Be aware of the following requirements of your environment if you use Oracle-specific code generation:

• You must use an Oracle11g or later version of JDBC driver, because Oracle-specific code generation requires JDBC statement caching functionality.

• The generic SQLJ run time library, runtime, is not supported for Oracle-specific code generation. You must have one of the following Oracle SQLJ run time libraries in the CLASSPATH:

  • runtime12.jar

  • runtime12ee.jar

  See Also:

  "Requirements for Using the Oracle SQLJ Implementation"

When coding a SQLJ application where Oracle-specific code generation will be used, be aware of the following programming considerations and restrictions:

• To use a nondefault statement cache size, you must include appropriate method calls in your code, because Oracle customizer stmtcache option is unavailable.

• Do not mix Oracle-specific generated code with ISO SQLJ standard generated code in the same application. However, if Oracle-specific code and ISO SQLJ standard code must share the same connection, do one of the following:

  • Ensure that the Oracle-specific code and ISO standard code use different SQLJ execution context instances. Refer to "Execution Contexts" for information about SQLJ execution contexts.

  • Place a transaction boundary, that is, as a manual COMMIT or ROLLBACK statement, between the two kinds of code.

  This limitation regarding mixing code is especially significant for server-side code, because all Java code running in a given session uses the same JDBC connection and SQLJ connection context.

• Do not rely on side effects in parameter expressions when values are returned from the database. Oracle-specific code generation does not create temporary variables for evaluation of OUT parameters, IN OUT parameters, SELECT INTO variables, or return arguments on SQL statements.

  For example, avoid statements such as the following:

  #sql { SELECT * FROM EMPLOYEES INTO :(x[i++]), :(f_with_sideffect()[i++]),
                                :(a.b[i]) };
  

  or:

  #sql x[i++] = { VALUES f(:INOUT (x[i++]), :OUT (f_with_sideffect())) };
  

  Evaluation of arguments is performed in place in the generated code. This may result in different behavior than when evaluation is according to ISO SQLJ standards.

• Type maps for Oracle object functionality assumes that the corresponding Java classes implement the java.sql.SQLData interface. If you use type maps for Oracle object functionality, then your iterator declarations and connection context declarations must specify the same type maps. Specify this through the with clause.

  For example, if you declare a connection context class as follows:

  #sql context TypeMapContext with (typeMap="MyTypeMap");
  

  and you populate an iterator instance from a SQLJ statement that uses an instance of this connection context class, as follows:

  TypeMapContext tmc = new TypeMapContext(...);
  ...
  MyIterator it;
  #sql [tmc] it = ( SELECT pers, addr FROM tab WHERE ...);
  

  then the iterator declaration is required to have specified the same type map, as follows:

  #sql iterator MyIterator with (typeMap="MyTypeMap") 
                (Person pers, Address addr);
  

  See Also:

  "Custom Java Class Requirements" and "Declaration WITH Clause"

  Note:

  The reason for this restriction is that with Oracle-specific code generation, all iterator getter methods are fully generated as Oracle JDBC calls during translation. To generate the proper calls, the SQLJ translator must know whether an iterator will be used with a particular type map.

General SQLJ Notes

Local Variable Naming Restrictions

Some of the functionality of the SQLJ translator results in minor restrictions in naming local variables. The SQLJ translator replaces each SQLJ executable statement with a statement block, where the SQLJ executable statement is of the standard syntax:

#sql { SQL operation };  

SQLJ may use temporary variable declarations within a generated statement block. The name of any such temporary variables will include the following prefix:

 __sJT_

The following declarations are examples of those that might occur in a SQLJ-generated statement block:

int __sJT_index;
Object __sJT_key;
java.sql.PreparedStatement __sJT_stmt;

The string __sJT_ is a reserved prefix for SQLJ-generated variable names. SQLJ programmers must not use this string as a prefix for the following:

• Names of variables declared in blocks that include executable SQL statements

• Names of parameters to methods that contain executable SQL statements

• Names of fields in classes that contain executable SQL statements, or whose subclasses or enclosed classes contain executable SQL statements

Class Naming Restrictions

Be aware of the following minor restrictions in naming classes in SQLJ applications:

• You must not declare class names that may conflict with SQLJ internal classes. In particular, a top-level class cannot have a name of the following form, where a is the name of an existing class in the SQLJ application:

  a_SJb
  

  where, a and b are legal Java identifiers.

  For example, if your application class is Foo in file Foo.sqlj, then SQLJ generates a profile-keys class called Foo_SJProfileKeys. Do not declare a class name that conflicts with this.

• A class containing SQLJ executable statements must not have a name that is the same as the first component of the name of any package that includes a Java type used in the application. Examples of class names to avoid are java, sqlj, and oracle (case-sensitive). As another example, if your SQLJ statements use host variables whose type is abc.def.MyClass, then you cannot use abc as the name of the class that uses these host variables.

  To avoid this restriction, follow Java naming conventions recommending that package names start in lowercase and class names start in uppercase.

SQLJ source files have the .sqlj file name extension. If the source file declares a public class (maximum of one), then the base name of the file must match the name of this class (case-sensitive). If the source file does not declare a public class, then the file name must still be a legal Java identifier, and it is recommended that the file name match the name of the first defined class.

For example, if you define the public class MySource in your source file, then your file name must be:

MySource.sqlj