ABOUT SQLJ

INTRODUCTION

SQLJ is an outdated 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).

ANSI AND ISO STANDARDS

SQLJ part 0: ANSI X3.135.10-1998, "Database Language SQLPart 10: Object

Language Bindings (SQL/OLB)"

SQLJ part 1: ANSI NCITS 331.1-1999, "SQLJPart 1: SQL Routines Using the Java
Programming Language"

SQLJ part 2: ANSI NCITS 331.2-2000, "SQLJPart 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 technologyDatabase languagesSQLPart

10: Object Language Bindings (SQL/OLB)

1
 ISO/IEC 9075-13:2002, Information technologyDatabase languagesSQLPart
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 AND DISADVANTAGES

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 INCLUDE:

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.

2
SQLJ EXAMPLE

#sql private static iterator

EmployeeIterator(String, String,
BigDecimal);

...EmployeeIterator iter;

#sql [ctx] iter = {

SELECT LASTNAME

, FIRSTNME

, SALARY

FROM DSN8710.EMP

WHERE SALARY BETWEEN :min

AND :max

};

do {

#sql {

FETCH :iter

INTO :lastname, :firstname, :salary

3
 };

// Print row...

} while (!iter.endFetch());

iter.close();

SERVER ARCHITECTURE

SQLJ, which stands for "SQL-Java," is a multi-part specification for using SQL with Java:

Part 0: Embedded SQL in Java. This provides a somewhat more object-oriented

approach to the standard way of embedding SQL statements in programs. Part 0
supports static SQL statements in Java. It does not support dynamic SQL statements.
Those are handled by JDBC. Part 0 does support mixing embedded static SQL
statements with JDBC statements. Part 0 supports the same mapping between Java
data types and SQL data types that is defined by JDBC. Also see the SQLJ Execution
Environment.

Part 1: SQL routines using Java. This provides the ability to invoke methods
written in Java from SQL code. The Java methods provide the implementation of SQL
procedures. To support Part 1, a DBMS must have a Java Virtual Machine associated
with it. Part 1 deals only with static methods. For an association between SQL
functions and Java methods, each SQL parameter and its corresponding Java
parameter must be able to be mapped and the two return types must be able to be
mapped. Also see mapping SQL and Java data types.

Part 2: SQL types using Java. This defines SQL extensions for using Java classes as
data types in SQL. Part 2 allows mapping of SQL:1999 User Defined Types (UDTs)
to Java classes. It also allows importing a Java package into your SQL database by
defining tables containing columns whose data type are specified to be a Java class.
Structured types are associated with classes, attributes with fields, and initializers to
constructors. All or part of an SQL type hierarchy can be represented in a Java class
hierarchy. It is not necessary to associate the entire SQL type hierarchy to a Java

4
 hierarchy. Part 2 adds non-static methods to the static methods in Part1. Also see
SQL:1999.

The mapping of Java to the attributes of SQL:1999 typed tables is more or less
straightforward. There are, however, Java structures that do not map exactly to SQL
structures. For example, a vector structure could be mapped to a fixed length ARRAY
type, sets also could be mapped to a fixed length ARRAY type, and lists may be more
problematic to map and may depend on how you are using them. You also have the
option, instead of using typed tables, to store Java objects in a serialized byte stream
as an SQL BLOB (Binary Large OBject). The BLOB representing the object would
then be stored in a cell of a table. With the SQL BLOB approach, it is still possible to
define methods that operate on the object. Either way, there will remain some
impedance mismatch between Java and SQL:1999. See impedance mismatch.

SQLJ uses the embedded database sublanguage approach when using the Java
programming language. This is illustrated by the embedded SQL statements in this diagram.

An example of a Part 0 embedded SQLJ statement that creates a new Person instance
with a Social Security Number of "999999999" would be:

#sql

{ INSERT
INTO person

5
 VALUES ('999999999', 'Doug Barry');
};

This code would then be processed by a SQLJ Part 0 Translator, which will look for
these embedded statements and replace them with Java statements that cause the SQL
statements to be executed. The code shown above would be in addition to any host
programming code.

If you also wanted to manipulate this new Person instance in the host program, you
would need Java code in addition to this code fragment that populates the instance in Java
along with the instance in the database.

CONCLUSION

SQLJ was developed by The SQLJ Group, a consortium comprised of database

vendors and Sun Microsystems. The SQLJ Group submitted SQLJ in three parts to the
INCITS Technical Committee H2 on Database. H2 has adopted the three parts into the SQL
standard.

REFERENCES

http://www.service-architecture.com/articles/database/sqlj.html
http://searchsoa.techtarget.com/definition/SQLJ
https://en.wikipedia.org/wiki/SQLJ
http://www.service-architecture.com/articles/database/sqlj.html