jOOQ and Vaadin: Lowering the Cost of Infrastructure Work

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:

  .select(ADDRESS.COUNTRY, count())

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 and why I talk a lot about SQL at Java conferences (I’m always the only one!) and deliver SQL trainings 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! 

Thanks Lukas for sharing your knowledge. Keep being so awesome for the Java community!

Read the guide and try jOOQ with Vaadin

Getting started with IntelliJ IDEA and NetBeans

The latest Vaadin Community Survey showed that Eclipse is still the most used IDE to develop Vaadin applications. IntelliJ and NetBeans, nevertheless, make a not negligible 40% of the share:


Most content out there is tailored to Eclipse users, and although Vaadin is IDE-agnostic, I figured it’d be worthwhile to show how simple it is to set up IntelliJ IDEA and NetBeans with Vaadin. You can find these new videos below and also in the getting started page.

So, if you are a visual learner, watch the videos, try them by yourself, and let me know in the comments section what else you would like to see in future videos.

Getting started with Vaadin in IntelliJ IDEA

Getting started with Vaadin in NetBeans

Subscribe to the Vaadin YouTube Channel


Dependency Injection, black magic or a must have tool for a modern Java application?

If you have passed your courses about object oriented programming, you know that loose coupling is something you should always strive for. There are many ways to achieve loose coupling. Inversion of control (IoC) using dependency injection (DI) is one way to improve the quality of your code.

When a developer asks me how they should build a “full-stack application”, I pretty much always suggest basing their application either on Java EE or Spring. One of the reasons is the DI containers that both technology stacks provide. Many developers and architects are a bit afraid of this “magic” that inversion of control and dependency injection bring in, often for the wrong reasons.

Last week we had a webinar with my colleague Petter Holmström about dependency injection. If you want to get an idea of what dependency injection is or just want to refresh your knowledge of the subject, you should definitely check it out. In the webinar we discuss if, why and when you should use dependency injection in your applications and go through the basic principles and alternatives.

The key takeaways of our webinar:

  • Loose coupling and high cohesion (and all the advantages they bring) are the main things we aim for with DI.

  • When starting with DI, learn the basic concepts well and watch out for the pitfalls. Otherwise the DI container will cause you more harm than good.

  • Contexts and events will further help you create reusable and maintainable code.

  • There is no need to bring in “all the magic” of the Spring or Java EE technology stacks. I like to use DI even in the simplest cases because Vaadin CDI and Vaadin Spring make it easier to use Vaadin compared to the plain servlet approach and setting everything up yourself.

  • There are multiple DI containers to choose from. Vaadin has integrations for three of them:

  • There are also alternative mechanisms that you can use if you for some reason aren’t able to use a DI container. Simply by designing your code using IoC patterns, you can achieve loose coupling and high cohesion.

Our Java EE training also discusses DI and how to use it in your Vaadin applications. If you want more hands on training about dependency injection, join our next course!

Learn more about Vaadin Trainings