SQLJ

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.
  • 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 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.

Embedded database sublanguage

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.

>>
For an architectural example of how JDBC can be used, see Using SQLJ with Application Servers.

┬╣ Using "SQLJ" avoids possible trademark problems with using the word "Java."

Related Articles

More detail for the current topic: SQLJ

More on the general topic: DBMS Standards

You may use this material for your work or classes. Reprint Policy. Be sure to check the menu at the left for other articles available on this site.

The Savvy Manager's Guide

Douglas K Barry is also the author of a book that explains Web Services, service-oriented architecture, and Cloud Computing in an easy-to-understand, non-technical manner.

Web Services, Service-Oriented Architectures, and Cloud Computing: The Savvy Manager's Guide

Web Services, Service-Oriented Architectures, and Cloud Computing: The Savvy Manager's Guide (Second Edition)

by with David Dick

This is a guide for the savvy manager who wants to capitalize on the wave of change that is occurring with Web Services, service-oriented architecture, and—more recently—Cloud Computing. The changes wrought by these technologies will require both a basic grasp of the technologies and an effective way to deal with how these changes will affect the people who build and use the systems in our organizations. This book covers both issues. Managers at all levels of all organizations must be aware of both the changes that we are now seeing and ways to deal with issues created by those changes.

Also by Douglas K Barry

Latest Post on the
Design Decomposition Blog
Upcoming Webinar
I will be presenting a webinar on January 21. Topic: Managing Change Needed for Service-Oriented Architectures and Cloud Computing. Description: Service-Oriented Architecture (SOA) and Cloud Computing projects are no different from other IT projects in that larger projects tend to fail and issues regarding people and change can scuttle projects. Oftentimes, such change issues are...
January 6, 2014