java - vs Comparing Querydsl, jOOQ, JEQUEL, activejdbc, iciql and other query DSLs

1 Answers

You should also look at MyBatis Statement Builder.

While MyBatis is clearly a mapping technology it does have a Statement builder DSL that seems to be decoupled from MyBatis (that is you don't need anything else from MyBatis to use the builders... annoyingly its not in its own jar). I don't like it because it uses ThreadLocals.

sql dsl java

Can someone point me to some resources about the performance comparison among the different Query DSL libraries available for using with Java, like: Querydsl, jOOQ, JEQUEL, activejdbc, iciql and etc...

Background: I m using Spring JDBC template, but that still required the queries to be written in plain string format. Although I don't have issues in writing the direct queries, but I m concerned having direct dependency on DB table names. I don't want to use any ORM framework like Hibernate or JPA/EclipseLink. I need the raw performance as high as possible (IMO, they are good for more CRUD centric applications). I can afford some slight overhead for the these DSLs only if that is a little (I believe, it'll be mostly StringBuilder/String concatenations!)

I've considered using named queries externalised in some xml. But just trying to evaluate the value different Query DSL libraries provide.

Edit: more on my requirement: I want to know the performance comparison among these when building a moderately complex query using their API methods. All I need is to generate a query string using any of these query DSL libraries and pass that to Spring JDBC template. So, I want to know if addition of this intermediate step incurs considerable performance penalty, I want to use named queries or build my own library which just uses StingBuilder or similar approach

update my experience with jOOQ, iciql, QueryDSL:

All though I missed to mention this in my original post, I m also keen about the ease of use & the overhead I need to have in my entity classes (like if any additional annotations or implementations required).


  • requires changing the entity properties to the library specific way
  • can return SQL query string


  • entity can be mapped with no or little changes (can be mapped using total 3 ways)
  • but with that it limits to only select queries (for update/delete/... requires entity changes again)


  • multiple ways to bind entities with table (other than library specific ways, using JPA annotations is supported). but we need to modify the entities at least
  • no simple/direct way to get the query string

(all observations are with little knowledge I've on these; if any of these are incorrect, please correct)

With all of the above, I m sticking with writing named queries :( But as the Lukas Eder answer seems explains about my original post concern (performance), I've accepted his.