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.
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 (new window).
- 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 (new window).
- 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 hierarchy. Part 2
adds non-static methods to the static methods in Part1. Also see SQL:1999 (new window).
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 (new window).
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
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.
¹ Using "SQLJ" avoids possible trademark problems with using the word "Java."
More detail for the current topic: SQLJ
More on the general topic: DBMS standards
