BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Quaere: LINQ Arrives for Java

Quaere: LINQ Arrives for Java

This item in japanese

Bookmarks

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 =
 from("p").in(products).
 select("p.getProductName()");

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
Style

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.

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

Community comments

  • link broken

    by Runar Svendsen,

    Your message is awaiting moderation. Thank you for participating in the discussion.

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

  • Type safety?

    by Peter Monks,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Fixed the link. Thanks for the catch!

  • Lost in HTML

    by Anders Norås,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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 =
    from("p").in(products).
    select("p.getProductName()");


    Cheers,
    Anders

  • Type safety using decompilation

    by Thomas Mueller,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Using Strings does not provide type safety. With current Java it is still possible:

    Test t = db.alias(Test.class);
    db.from(t).where(t.id == 1).select(t.id, t.name);

    The problem here is how to convert 't.id == 1' and 't.id, t.name' 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 (www.h2database.com)

  • Re: Type safety using decompilation

    by Thomas Mueller,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Ehm... one more problem: where(t.id == 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(t.id == 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,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    A solution without decompilation:

    class Test {
    Integer id;
    String name;
    }
    Test t = alias(Test.class);
    from(t).where(equal(t.id, x)).select(t.id, t.name);

    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,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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 = DbInt.pk();
    public DbString name;
    }
    ...
    Person p = Person.TABLE;
    Person found = db.from(p).where(p.id.eq(10)).get();
    for (Person a : db.from(p).
    order(p.id.asc(), p.name.desc()).
    select()) {
    System.out.println(a.name.value);
    }
    Person one = db.from(p).
    where(p.id.eq(x).and(p.name.eq(name))).
    get();

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

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

BT