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. See also 
 Embedded SQL
 Language Integrated Query (LINQ)

References

Further reading 
 Connie Tsui, Considering SQLJ for Your DB2 V8 Java Applications, IBM developerworks, 13 Feb 2003
 Owen Cline, Develop your applications using SQLJ, IBM developerworks, 16 Dec 2004

External links 
 IBM Redbook: DB2 for z/OS and OS/390: Ready for Java
 Oracle SQLJ Developers Guide

Database Connectivity
Database APIs
SQL data access