InfoQ

News

Quaere: LINQ Arrives for Java

Posted by Rob Thornton on Sep 20, 2007 07:30 AM

Community
Java
Topics
Artifacts & Tools
Tags
LINQ

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.

8 comments

Reply

link broken by Runar Svendsen Posted Sep 20, 2007 9:24 AM
Re: link broken by Rob Thornton Posted Sep 20, 2007 3:25 PM
Type safety? by Peter Monks Posted Sep 20, 2007 1:29 PM
Lost in HTML by Anders Norås Posted Sep 20, 2007 3:38 PM
Type safety using decompilation by Thomas Mueller Posted Sep 21, 2007 2:03 AM
Re: Type safety using decompilation by Thomas Mueller Posted Sep 21, 2007 2:34 AM
Type safety using objects by Thomas Mueller Posted Sep 21, 2007 4:49 AM
Type safety using objects / 2 by Thomas Mueller Posted Sep 21, 2007 10:57 AM
  1. Back to top

    link broken

    Sep 20, 2007 9:24 AM by Runar Svendsen

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

  2. Back to top

    Type safety?

    Sep 20, 2007 1:29 PM 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?

  3. Back to top

    Re: link broken

    Sep 20, 2007 3:25 PM by Rob Thornton

    Fixed the link. Thanks for the catch!

  4. Back to top

    Lost in HTML

    Sep 20, 2007 3:38 PM 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 =
               from("p").in(products).
               select("p.getProductName()");
    
    Cheers, Anders

  5. Back to top

    Type safety using decompilation

    Sep 21, 2007 2:03 AM 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(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)

  6. Back to top

    Re: Type safety using decompilation

    Sep 21, 2007 2:34 AM by Thomas Mueller

    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?

  7. Back to top

    Type safety using objects

    Sep 21, 2007 4:49 AM by Thomas Mueller

    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 (=, >, <, +,...).

  8. Back to top

    Type safety using objects / 2

    Sep 21, 2007 10:57 AM 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 = 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();
    

Exclusive Content

Rustan Leino and Mike Barnett on Spec#

Rustan Leino and Mike Barnett of Microsoft Research discuss the technology in Spec# and its futures.

10 Ways to Screw Up with Scrum and XP

Henrik Kniberg talks about 10 possible reasons to fail while doing Scrum and XP. Maybe the team does not have a definition of what Done means to them, or they don't know what their velocity is.

Tips from a Top Sports Team Coach

This article outlines 9 principles Marc Lammers discovered while building the world’s best field hockey team, mapping them to software development practices.

SOA Governance: An Enterprise View

Michael Poulin explains the necessity for SOA governance to ensure an Enterprise SOA's success, relying on concepts from the OASIS SOA Reference Model and Reference Architecture.

Developing Portlets using JSF, Ajax, and Seam (Part 2 of 3)

This article covers setting up a RichFaces portlet using JBoss Portlet Container and JBoss Portlet Bridge, deploying a RichFaces portlet, and RichFaces capabilities.

Scalability Worst Practices

This article discusses scalability worst pratices including The Golden Hammer, Resource Abuse, Big Ball of Mud, Dependency Management, Timeouts, Hero Pattern, Not Automating, and Monitoring.

Do the Hustle

Obie Fernandez shares his experience selling consulting services for both Thoughtworks and Hashrocket and give tips how Ruby developers can work with clients.

Natural Laws of Software Development - Deriving Agile Practices

Jeffries and Hendrickson derive Agile practices from the natural laws of software development. They don't just say "Be Agile!", but they explain why Agile practices make perfect sense.