Why Did SQLJ Die?

Every now and then, SQLJ pops up somewhere, mostly in a very dusty/enterprisey or in an academic context.

If you give SQLJ some thought, though, it isn’t such a bad idea. It is:

  • An ANSI and ISO standard
  • Part of the SQL standard
  • Quite easy to understand
  • Quite a powerful extension to JDBC

So why did it die (or rather, why did it never really take off)? This question was asked on Stack Overflow, and we gave an answer.

Let’s assume that you have already decided to embed your SQL (as opposed to externalising it through a templating mechanism, hiding it with an ORM, or with stored procedures). Here are a couple of reasons why SQLJ is not an optimal solution for embedding SQL:

IDE support

While Pro*C worked well for C and C++ in the 90s, Java really took off in the early 2000’s. With Java, there were also an increasing number of powerful IDEs such as Eclipse, NetBeans, JBuilder, and others. Java preprocessors and IDEs have never become friends, though, as parsing one language is hard enough. Parsing (and providing tooling) for two languages is much harder.

In fact, SQLJ made the surrounding Java code type-unsafe as IDEs and compilers couldn’t process .sqlj files before they had been pre-processed.

SQL popularity

There was a time when people started thinking that SQL itself was going to be dead. First, they did so with the advent of ORMs, then they did so with the advent of NoSQL. People thought that the DBA is dead. Again.

Well, this has been proven to be wrong a couple of times, but certainly not because of SQLJ.

Typesafety

In the late 2000’s, there had now been typesafe alternatives to SQLJ, such as jOOQ in Java, or LINQ-to.SQL in .NET, which leverage IDE features such as syntax autocompletion. By being internal domain-specific languages / query DSLs, these APIs not only bring typesafety to embedded SQL, but they also allow for dynamic SQL building, which SQLJ doesn’t support.

Predictions

While embedding SQL into other languages is a useful thing, SQLJ never solved this problem adequately. Hence, R.I.P., SQLJ

ElSql, a new external SQL DSL for Java

Stephen Colebourne who is frequently commenting on the lambda-dev and other Java 8 mailing lists, has recently published an idea he has been having for a while: ElSql, a new external SQL DSL for Java.

An example SQL statement is given on the blog posts or on GitHub:

 @NAME(SelectBlogs)
   @PAGING(:paging_offset,:paging_fetch)
     SELECT @INCLUDE(CommonFields)
     FROM blogs
     WHERE id = :id
       @AND(:date)
         date > :date
       @AND(:active)
         active = :active
     ORDER BY title, author
 @NAME(CommonFields)
   title, author, content

As can be seen, this is almost mere string-based SQL, enhanced with some “hooks” for later use in Java. While Stephen’s idea here is to keep it simple (much simpler than jOOQ) it shows some useful applications of allowing to write external DSLs which resemble SQL even more than jOOQ.

DSL authoring support is becoming a more and more interesting topic in various platforms. Eclipse is developing Xtext, Scala is experimenting with even more powerful Macros. While Xtext doesn’t allow to mix the DSL grammar with Java, Scala’s Macros do precisely that. They allow for simple compile-time checked Scala syntax extension, if you have a powerful enough CPU to compile such source code. Where this could go for jOOQ was discussed on this blog before

For more details, read about ElSql on Stephen’s or the OpenGamma blog: