jOOQ and Vaadin: Lowering the Cost of Infrastructure Work
Check out this interview with jOOQ leader and Java Champion Lukas Eder. See what he has to say about jOOQ and how it and Vaadin can make for a friendly infrastructure.
I had the pleasure of talking with Lukas Eder, Java Champion and member of the board of the Java User Group Switzerland. Lukas has been a speaker at many Java conferences, such as Geekout, Geecon, and Devoxx, for many years. He also is the founder and CEO of Data Geekery, the company behind jOOQ, a framework that, I would say, matches the philosophy of the Vaadin framework. Let’s find out his thoughts about it.
Hi Lukas, thanks for accepting the invitation. So, let’s get right to the topic... Can you tell us about jOOQ? How does it work? When is jOOQ a great option?
jOOQ models the entire SQL language as a fluent Java API, i.e. it is an internal domain-specific language. In essence, it’s “just” type safe JDBC, so whatever works in SQL/JDBC will also work in jOOQ, except that your Java compiler can type check both your SQL syntax and your database schema. An example:
DSL.using(configuration) .select(ADDRESS.COUNTRY, count()) .from(CUSTOMER) .join(ADDRESS).on(CUSTOMER.ADDRESS_ID.eq(ADDRESS.ADDRESS_ID)) .groupBy(ADDRESS.COUNTRY) .orderBy(ADDRESS.COUNTRY.desc()) .fetch();
This is a very simple query counting the number of customers per country. jOOQ users use jOOQ for simple but also for extremely complex SQL queries with thousands of lines of type safe SQL in Java. Imagine a huge statement and now some developer renames a column. The huge statement will no longer compile and the Java compiler will immediately show what the problem is.
When executing the above query, jOOQ can translate the standardized SQL statement to any of the currently supported 21 RDBMS dialects, while still providing the full power of standard and vendor-specific SQL.
There are lots of additional features in jOOQ (such as SQL AST transformation), but in short, jOOQ is type safe JDBC and it’s great for anyone who wants to tightly integrate with their RDBMS, making SQL a first class citizen in a data intensive application.
Some developers might think that it's better/safer to use JPA because it’s "standard". Any thoughts about this?
I don’t think you can compare jOOQ with JPA on a mere technical level. jOOQ is more like JDBC – an SQL API. JPA solves the object graph persistence problem which has nothing to do with SQL. Unfortunately, many people default to JPA because they don’t want to do JDBC. That’s a shame, because SQL is an awesome language, but JDBC just doesn’t make it that awesome for Java developers.
Standards arguments make total sense in some environments where compliance is important, but like Vaadin, jOOQ is used by a large community of developers. Different surveys estimate jOOQ to hold between 2%-8% of market share compared to JDBC, JPA, MyBatis, and all the others. So, jOOQ is the de facto standard for type safe embedded SQL.
Also, jOOQ is an extremely simple library, which is Open Source and very easy to extend. Remember, it’s just type safe JDBC. This means that you don’t really write jOOQ code, you write SQL, which is itself an ISO standard – a much more important and more popular standard than JPA, by the way. There are many libraries similar to jOOQ because type safe embedded SQL has always been the dream of many Java developers. Even JPA has a similar API, which is called Criteria Query. It only works for JPQL though, not for SQL. This is where jOOQ comes in. It offers a type safe embedded SQL API for standard SQL.
What’s the "killer feature" of jOOQ?
The killer feature is the mindset that jOOQ enables and encourages in developers. jOOQ makes developers extremely productive, because it is very well integrated into the Java language and into data centric architectures, for example architectures that make use of Java 8 streams. It makes SQL a first class citizen in Java (which it should be).
Once developers start using jOOQ, their applications become much simpler, leaner, more fun to write and maintain, less error prone, and thus more valuable for their customers. That should be *the* killer feature of every technology.
jOOQ makes it possible to use Java for your SQL queries, a bit similar to how Vaadin makes it possible to use Java for your HTML UIs. Sounds like a good match, doesn't it?
Absolutely. Both frameworks “wrap” external languages/technologies (HTML, SQL) in a way for those languages to become more native to Java developers. While Vaadin is built for the web, jOOQ is built for relational databases.
An ideal database backed web application would use jOOQ to run sophisticated SQL statements, Java 8 to transform data streams into Vaadin UI objects, and Vaadin to display database output to the user.
In such an architecture, developers could lower the cost of infrastructure work (bridging HTML+Java, bridging SQL+Java) by using two APIs that solve all of these infrastructure problems.
What can you share about the future of jOOQ?
Much like SQL, jOOQ has a bright future.
We’re currently working on an SQL parser that can parse any SQL dialect and with the existing jOOQ feature set, translate (and optionally: format) an SQL string to any other SQL dialect.
We’re going to add more features in the DDL space, to help users write type safe schema migrations similar to Liquibase, but in a much more general and complete way.
We’re experimenting with temporal validity and the emulation of the SQL:2011 standard syntax into databases that do not support this feature.
Also, we’re here to help our users write better SQL. This is why we blog at http://blog.jooq.org and why I talk a lot about SQL at Java conferences (I’m always the only one!) and deliver SQL training to Java shops.
Anything else you would like to say to the Vaadin developers evaluating backend technologies?
Do check out jOOQ. jOOQ makes SQL feel the way it should have always been: a part of Java. Once you’ve tried jOOQ, there’s no looking back. You’ll write awesome SQL whenever you can, because it’s a lot of fun and very productive!