Search alternative for QueryDSL

[hylkevds]

It seems QueryDSL is not actively maintained. The last release is over a year old, and the last commit is 11 months old.
While implementing a backend with UUID IDs, @selimnairb noticed that QueryDSL does not support UUIDs well yet. It doesn't have to be nearly as complex as QueryDSL, since we don't need the JPA/JDO bits, and we can also do without the code generation bits.

Therefore we should look for an alternative to QueryDSL. If anyone has suggestions, please share.

One option would be jOOQ: https://github.com/jOOQ/jOOQ

[hylkevds]

I've managed to create an implementation of the PersistenceManager that uses JOOQ instead of QueryDSL. It passes all our tests. Currently only long ids.

There are some interesting design differences between JOOQ and QueryDSL. The biggest difference is between the QueryDSL Expression and the JOOQ Field that both represent Columns, constants and other "expressions" in queries.

• JOOQ's Field<DataType> is not sub classed and the default implementation is final.
• QueryDSL's Expression is heavily sub classed: NumberExpression, ComparableExpression, etc.

As a result, in QueryDSL, the operations you can do on an Expression are determined by the specific interface that Expression implements. In JOOQ, all operations are defined in Field, so there is nothing stopping you from multiplying a Field<String> with a Field<Number>, and JOOQ will claim the result is a Field<String>.
The advantage of the JOOQ way is that if you have a Field type that JOOQ doesn't know, it is easy to make it work. For our use this type safety is not an issue, since our ExpressionHandler already makes sure things are correct.

Since Field can not really be sub classed, and our ExpressionHandler needs some way to pass our special Field types, I had to create a FieldWrapper interface with several implementations. In the end I think this is even cleaner than what I did in the QueryDSL back ends.

Another difference is that QueryDSL is very flexible in the order in which you add the different parts (join, where, from, etc) to the SQL query. JOOQ enforces a strict order, and you can't really have if statements in between, since every step returns a different interface. As a result I had to change the piecemeal way of building the query we used so far to a "first gather all data, then build the query in one go" approach. In itself also not a bad change.

I'll implement the other two ID types, and add the JOOQ back-end as a separate option to the master branch at first. After testing more thoroughly I may at some point replace the QueryDSL back-ends with the JOOQ versions.