SQLJ

SQLJ is a working title for efforts to combine Java and SQL. It was a common effort started around 1997 by engineers from IBM, Oracle, Compaq, Informix, Sybase, Cloudscape and Sun Microsystems.

It consists of the three parts: 0, 1 and 2. Part 0 describes the embedding of SQL statements into Java programs. SQLJ part 0 is the basis for part 10 of the SQL:1999 standard, aka SQL Object Language Bindings (SQL/OLB). SQLJ parts 1 and 2 describes the converse possibility to use Java classes (routines and types) from SQL statements. Parts 1 and 2 are the basis for part 13 of the SQL standard, SQL Routines and Types Using the Java Programming Language (SQL/JRT).

"SQLJ" is commonly used to refer to just SQLJ part 0, usually when it is contrasted with other means of embedding SQL in Java, like JDBC.

ANSI and ISO standards

 * SQLJ part 0: ANSI X3.135.10-1998, "Database Language SQL—Part 10: Object Language Bindings (SQL/OLB)"
 * SQLJ part 1: ANSI NCITS 331.1-1999, "SQLJ—Part 1: SQL Routines Using the Java Programming Language"
 * SQLJ part 2: ANSI NCITS 331.2-2000, "SQLJ—Part 2: SQL Types Using the Java Programming Language"

Part 0 was updated for JDBC 2.0 compatibility and ratified by ISO in 2000. The last two parts were combined when submitted to ISO. Part 2 was substantially rewritten for the ISO submission because the ANSI version was not formal enough for a specification, being closer to the style of a user manual. The combined version was ratified in 2002.


 * ISO/IEC 9075-10:2000, Information technology—Database languages—SQL—Part 10: Object Language Bindings (SQL/OLB)
 * ISO/IEC 9075-13:2002, Information technology—Database languages—SQL—Part 13: SQL Routines and Types Using the Java Programming Language (SQL/JRT).

SQLJ part 0
The SQLJ part 0 specification largely originated from Oracle, who also provided the first reference implementation.

In the following SQLJ is a synonym for SQLJ part 0.

Whereas JDBC provides an API, SQLJ consists of a language extension. Thus programs containing SQLJ must be run through a preprocessor (the SQLJ translator) before they can be compiled.

Advantages
Some advantages of SQLJ over JDBC include:
 * SQLJ commands tend to be shorter than equivalent JDBC programs.
 * SQL syntax can be checked at compile time. The returned query results can also be checked strictly.
 * Preprocessor might generate static SQL which performs better than dynamic SQL because query plan is created on program compile time, stored in database and reused at runtime. Static SQL can guarantee access plan stability. IBM DB2 supports static SQL use in SQLJ programs.

Disadvantages

 * SQLJ requires a preprocessing step.
 * Many IDEs do not have SQLJ support.
 * SQLJ lacks support for most of the common persistence frameworks, such as Hibernate.
 * Oracle 18c (12.2) has desupported SQLJ in the database.

Examples
The following examples compare SQLJ syntax with JDBC usage.