As an RPG programmer, I don’t often use SQL to interact with DB2 data; I don’t have to. RPG is an excellent language to use for database access. With operations such as CHAIN, READ, and UPDATE, I have plenty of native RPG methods to relate to relational databases. But if I don’t want to use native RPG operations to interact with DB2, I can embed SQL right into my RPG code and use Select statements instead of CHAIN operations. This might be handy if I were learning RPG but already well-versed in SQL.

If RPG Can Do It...

I am also learning Java, and the first thing I wanted to do with it was access my AS/400 data. So I started messing around with the Java Database Connectivity (JDBC) API. JDBC provides a way to use native Java commands instead of SQL to get at SQL databases. This is great, but whenever I write JDBC code, I think of how easy it would be if I could simply add SQL statements instead. Well, Oracle, IBM, Sybase, Tandem, Javasoft, and Informix have put their collective heads together to come up with a highly productive, open multivendor standard for embedding static SQL into Java code: SQLJ.

Show Me the Benefits

SQLJ allows you to embed SQL statements directly into Java code. Once SQL statements are embedded, they must be run through the SQLJ translator, which converts SQLJ code into 100% Pure Java code. (SQL statements are actually converted to JDBC 1.22 code. Check out FAQs on Oracle’s site www.oracle.com/java/sqlj/faq. html#39171 for more information on JDBC compatibility.) Once translated, the Java code is compiled into byte code and run, as usual. The SQLJ translator optionally performs SQL syntax checking, database schema checking, and variable type checking, all at translation time. Now, those of you familiar and comfortable with JDBC need not worry. Just as embedded SQL is an option in RPG, so it is in SQLJ, as Salmon Kahn, Thomas Kurian, and Brian Wright explain in their white paper “SQLJ: It’s Javalicious!” (www.oracle. com/java/documents/pdf/javalicious.pdf): “SQLJ does not replace JDBC—in fact, Oracle’s implementation of SQLJ uses JDBC. But for static SQL, where the SQL statements are known at development time, SQLJ provides a much more convenient and robust way to write your code.”

It seems that SQLJ adds flexibility to your Java database applications. Oracle documents other benefits and technical information nicely in its white paper “SQLJ: Embedded SQL in Java” (www.oracle.com/java/sqlj/collateral/SQLJTechnical .html). The following bullets summarize the application development benefits:

• SQLJ provides high-level embedded SQL syntax for easy database access. SQLJ code is more compact and contains a higher-level programming abstraction compared with JDBC, making it less prone to errors and easier to understand and maintain.

• The SQLJ translator performs type and schema checking to detect syntax and semantic errors at development time rather than runtime, as in JDBC.

• SQLJ provides a ConnectionContext Java object, which creates the JDBC Statement objects needed for dynamic SQL operations. Thus, SQLJ allows users to take advantage of the static and dynamic SQL functions within the same application.

Good News, Bad News

What do all these benefits cost? Not much, really. Any performance cost associated with SQLJ is seen at compile time—rather, translation time. Once the code is translated and compiled to a Java class, the performance is the same as using JDBC because that’s what SQLJ becomes. However, there is one exception to the rule. It has to do with IBM’s implementation of SQLJ. The good news is that OS/400 V4R4 supports both SQLJ and the translator developed by Oracle (Reference Interpreter, or RI). SQLJ works the same way, for the most part. You enter your embedded SQL statements, and they are translated to JDBC calls at compile time via the SQLJ command. The bad news is that IBM’s implementation of SQLJ does not allow for static SQL. According to IBM, there is no access plan associated with the compiled Java program. For this reason, IBM suggests that JDBC may be better for performance because it gives you more control over the JDBC code. IBM indicates that future releases of OS/400 will support static SQL in SQLJ. But for now, SQLJ in V4R4 is nothing more than a JDBC code writer.

The Verdict

SQLJ is a viable tool to help you write database applications in Java. It allows you to work directly with SQL, provides SQL syntax and semantic checking at compile time, and complements JDBC by allowing dynamic and static SQL statements in the same application. To learn more about SQLJ, check out Oracle’s SQLJ site at www.oracle. com/java/sqlj/index.html. To learn more about SQLJ on V4R4, visit the same site, but disregard anything that has to do with static SQL.