Quaere: LINQ Arrives for Java

| by Rob Thornton Follow 0 Followers on Sep 20, 2007. Estimated reading time: 1 minute |

Anders Noras introduced the Quaere library, billed as LINQ for Java, last week at JavaZone. Quaere is a DSL providing query functionality against any structure implementing Iterable or its Queryable interface.

Noras lists the features of Quaere:

  • Ability to perform queries against arrays or data structure implementing the Iterable interface.
  • An internal DSL (based on static imports and fluent interfaces) that lets you integrate the query language with regular Java code. No preprocessing or code generation steps are required to use the DSL, simply add a reference to the quaere.jar file (and its dependencies).
  • A large number of querying operators including restriction, selection, projection, set, partitioning, grouping, ordering, quantification, aggregation and conversion operators.
  • Support for lambda expressions.
  • The ability to dynamically define and instantiate anonymous classes.
  • Many new “keywords” for Java 1.5 and later.

An example of retrieving a list of product name’s from a list of products is:

List products = Arrays.asList(Product.getAllProducts()); 
Iterable productNames =

Quaere currently has only one implementation (for objects), but a partial implementation is in place for Hibernate. The Hibernate implementation (and others with good criteria APIs) should progress quickly, Anders notes, as the demo of Hibernate only took a few hours.

Several people have noted that joSQL is a similar API. Anders himself notes the similarities but points out some key differences including:

  • Quaere has better cohesion with the “business problem”
  • Quaere queries are much more compact and have type safety
  • Quaere is an extensible language that allows seamless addition of new querying engines

Lastly, Noras has made an attempt to answer common questions about Quaere and has created a project for it on Codehaus.

Rate this Article

Adoption Stage

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

link broken by Runar Svendsen

The Codehaus link at the end of the article is broken. This is the correct link.

Type safety? by Peter Monks

Given the use of strings in the select and presumably where clauses, is this truly type safe? Won't type safety require closures?

Re: link broken by Rob Thornton

Fixed the link. Thanks for the catch!

Lost in HTML by Anders Norås

First of all a big thank-you is due for writing about my humble project. Parts of the code example provided seem to have gotten "lost in HTML". Although the code in the example will compile and run, it should make use of generics to increase type safety.

List<Product> products = Arrays.asList(Product.getAllProducts());
Iterable<String> productNames =


Type safety using decompilation by Thomas Mueller

Using Strings does not provide type safety. With current Java it is still possible:
Test t = db.alias(Test.class);
db.from(t).where( == 1).select(,;

The problem here is how to convert ' == 1' and ',' into a expression tree (and then possibly SQL). Solution: get the calling class and line number. That's easy:
StackTraceElement e = new Error().getStackTrace()[0];
Class callingClass = e.getClass();
String method = e.getMethodName();
int line = e.getLineNumber();

Now, get the byte code of the class, decompile this method (harder but possible), and extract the expression tree. It can be done.

There are a few restrictions: 1) Requires debug info in the calling class. 2) Only one query per line of code. This can be solved: count how many times the method is called.

Maybe I should add this feature to my database (

Re: Type safety using decompilation by Thomas Mueller

Ehm... one more problem: where( == x)
But this can be solved as well: Require that each parameter is listed:
Query where(boolean condition, Object ... parameters)
The the query becomes:
where( == x, x)
The only problem now: You can't detect unknown parameters at regular compile time. This would require an additional compile step (_after_ the regular compilation). Any more problems?

Type safety using objects by Thomas Mueller

A solution without decompilation:
class Test {
Integer id;
String name;
Test t = alias(Test.class);
from(t).where(equal(, x)).select(,;

The method alias() would have to initialize the Test instance (assign a new object to each field). The methods equal() and select() could then check at runtime if such an object is passed and thus can reconstruct the expression tree. Disadvantages: int/long/double are not supported (except when using Integer.MIN_VALUE + 10, 11,..., but that would be a hack). A method is required for each operation (=, >, <, +,...).

Type safety using objects / 2 by Thomas Mueller

If you drop the POJO requirement, you could even get more type savety:
class Person {
static final Person TABLE = Db.alias(Person.class);
public DbInt id =;
public DbString name;
Person p = Person.TABLE;
Person found = db.from(p).where(;
for (Person a : db.from(p).
select()) {
Person one = db.from(p).

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

8 Discuss

Login to InfoQ to interact with what matters most to you.

Recover your password...


Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.


More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.


Stay up-to-date

Set up your notifications and don't miss out on content that matters to you