BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ
News Articles Presentations Podcasts Guides

Topics

Choose your language

QCon London

Adopt the right emerging trends to solve your complex engineering challenges. Attend in-person or online.
QCon New York

Find real-world practical inspiration from the world’s most innovative software leaders. Attend in-person or online.
QCon San Francisco

Learn what's next in software from world-class leaders pushing the boundaries. Attend in-person or online.
The Software Architects' Newsletter

Your monthly guide to all the topics, technologies and techniques that every professional needs to know about. Subscribe for free.

InfoQ Homepage News Two Type-Safe Criteria API Proposals for JPA 2.0

QCon New York (June 13-15): Learn best practices from senior developers at early adaptor companies.

Two Type-Safe Criteria API Proposals for JPA 2.0

Leia em Português

This item in japanese

Bookmarks

Jan 27, 2009 2 min read

Write for InfoQ

Join a community of experts. Increase your visibility.
Grow your career.Learn more

Introduced two years ago as part of Java EE 5, the Java Persistence API provides a POJO persistence model for object-relational mapping. It was developed by the EJB 3.0 software Expert Group as part of JSR-220.  

 Persistence consists of three areas:

  1. The API, defined in the javax.persistence package.
  2. The Java Persistence Query Language (JPQL).
  3. Object/relational metadata.

Whilst the JPQL significantly improved working with persistent Java objects, JPQL queries are still specified as strings. Thus whilst the queries operate over strongly-typed Java objects, they themselves are weakly typed.  Building up queries in this way can be error prone, and requires specific IDE support for validation, auto completion and refactoring.

JPA 2.0, which is being developed under JSR-317 for inclusion in Java EE 6, aims to address this through the introduction of a new criteria API that offers a non-string-based approach for building queries.  Expert Group lead Linda DeMichiel has published a blog entry describing the current draft of the API:

"Loosely speaking, a QueryDefinition object can be thought of as a set of nodes corresponding to the semantic constructs of the query: 
  • Domain objects, which correspond to the range variables and other identification variables of the JPQL FROM clause
  • Where clause predicates, which comprise one or more conditional expression objects
  • Select clauses, which comprise one or more "select item" objects
  • Order-by and group-by items
  • Subqueries

and so on..."

Whilst the proposal as it stands appears to be a good step forward from the existing JPA mechanism a number of people, amongst them Gavin King, have argued that the type safety of it could and should be further improved.  King, whose Hibernate O/R tool was amongst those that pioneered the use of a type-safe criteria API and was a significant influence on EJB3, has now submitted his own proposal to the Expert Group. His proposal exploits the javax.annotation.Processor introduced in Java 6 to allow a compiler plugin to build a metamodel type for each persistent class in the application.  King has written two blogs posts (one, two) which describe his approach in more detail and he and his team are currently working on a prototype annotation processor for use with javac.

The Expert Group is looking at the King proposal seriously and is considering it as a replacement for the current review draft.  DeMichiel told us:

"Discussion has largely focused on ensuring that this API leads to a better experience for developers, both for static queries (where the type-safe aspects should certainly shine), and for dynamic queries.  We are also looking at the metamodel generation aspects."

She added that the Expert Group is very keen to hear any feedback from the development community.  Please feed any comments in to jsr-317-pdr-feedback at sun dot com.

Rate this Article

Adoption
Style

This content is in the Java topic

Related Topics:

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

  • nice ..but

    by serge ----,

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

    far better than strings but the code generation is really just a work around for language features that should allow for easy creation of domain specific languages. Something comparable to linq can only be accomplished with some moderate language changes.

    Back to top
  • too complicated

    by Thomas Mueller,

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

    Very verbose. Code generation... I don't like it. It's probably too early to standardize this part.

    I wonder if they considered technology like JaQu, LIQUidFORM, or Querydsl. Example (JaQu):

    Product p = new Product();
    List<Product> soldOutProducts =
        db.from(p).where(p.unitsInStock).is(0).select();

    Back to top
  • Re: too complicated

    by Gavin King,

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

    Very verbose.


    Yes, both JPA criteria API proposals are significantly more verbose than the fluent style of API you exemplify, and at first Emmanuel and I were *really* concerned about this and were advocating for the fluent style.

    However, it turns out that some of the more complex cases just don't map as elegantly to the fluent style of API, and so the JPA group made the decision to go with the current approach. I'm still not 100% happy, but now that I'm used to it, I don't think it's a really bg problem. There is definitely more typing involved, however.

    Code generation... I don't like it.


    That's only because youve never used a Java6 Processor :-) It's not really "code generation" in the traditional sense at all. It's an extension to the type system that is built into the compiler. This is one of those things like annotations that are scary until you use them :-)


    I wonder if they considered technology like JaQu, LIQUidFORM, or Querydsl.


    Yes, I explain why these solutions don't work for us here:

    in.relation.to/Bloggers/Java6CompilerPluginsAnd...

    It's a nice idea, but it simply breaks down as soon as you want to write queries around anything other than a public attribute. Doesn't work with common JPA patterns.

    Back to top
  • Re: nice ..but

    by Gavin King,

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

    far better than strings but the code generation is really just a work around for language features that should allow for easy creation of domain specific languages


    Yes, of course Java should have method and attribute literals. It's absurd that this was left out of the language.

    But you can forget about getting them anywhere in the near future - let alone something like LINQ!

    Actually I don't personally think LINQ is the right direction anyway. Better to have some more general-purpose declarative constructs in the language, that can be used to solve other problems beside "querying".

    Back to top
  • Re: too complicated

    by William Smith,

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

    Gavin's blog just mention LIQUidFORM:


    "Unfortunately that particular approach forces you to represent every persistent attribute as a public getter method, which is not a restriction that is acceptable in the JPA specification."

    So I guess they will have looked at least some of them
    I’ve not looked at JaQu before – it looks very like writing SQL to me. What advantages does it offer over using something like raw JDBC and the Apache Dynabeans libraries?

    Back to top
  • Re: too complicated

    by Thomas Mueller,

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

    complex cases don't map elegantly


    But most cases are simple. I suggest to support both: simple conditions with fluent, complex expressions with your style.

    Code generation...


    Yes, the Processor solves that. I hope tools support will improve.

    queries around [non] public attribute


    In my view that's an edge case.

    Back to top
  • Re: too complicated

    by Thomas Mueller,

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

    What advantages does it offer over using something like raw JDBC and the Apache Dynabeans libraries?
    From the JaQu docs: auto-complete, type checking, protects against SQL injection, smaller than Hibernate, no XML, no annotations.

    Back to top
  • Re: too complicated

    by Gavin King,

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

    In my view that's an edge case.


    Actually it's an extremely common usecase to have private persistent field exposed only by getters that don't necessarily map exactly 1-1 to the fields.

    That's how at least 30% - perhaps more - people use JPA.

    Back to top
  • Re: too complicated

    by Gavin King,

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

    But most cases are simple. I suggest to support both: simple conditions with fluent, complex expressions with your style.


    Earlier today I sent an email to that effect to the JPA list. I'm not sure if it will go anywhere.

    Back to top
  • Re: nice ..but

    by serge ----,

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

    Joe Darcy is accepting language proposals for small changes to the jdk. I don't know if "method and attribute literals" are considered small but it would be nice to see something like this incorporated into the JDK. I know that FCM (closures proposal) had something like this - I suspect BGGA did also.

    Back to top
  • Cayenne experience

    by Andrus Adamchik,

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

    From Cayenne ORM experience that had typesafe queries from day one, and recently added type unsafe JPQL, the former, is a user choice over JPQL in 95% of cases, even though Cayenne SelectQuery is missing some of the capabilities of JPQL. So yeah, great to see type safe queries coming to JPA as well - that's the way to go.

    Back to top
  • Re: Cayenne experience

    by Andrus Adamchik,

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

    Just to clarify a bit, Cayenne "typesafe queries" are about building a query as an object made of parts vs. using a String. Type-safe criteria piece is still coming.

    Back to top
  • Re: too complicated

    by Rubem Azenha,

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

    I got a flashback when I was a "standard J2EE" developer, using tools like XDoclet and JBuilder for generating stubs, home, remote interfaces, local interfaces...

    Back to top
  • Re: too complicated

    by Rubem Azenha,

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

    I got a flashback *from* when ...

    Back to top
  • Re: too complicated

    by Emmanuel Bernard,

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

    About code generation flashback. I would like to emphasize what Gavin said. There is NO build time step to generate the metamodel. Thanks to the annotation processor magic built inside javac itself, the generation is part of the compilation. you don't even change the whay you invoke javac, just being in the classpath make annotation processors being triggered.

    Back to top
  • Re: too complicated

    by William Smith,

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

    I got a flashback when ...

    I think I liked the first version more!

    Something I find myself wondering about is how well this works when I have some reasonably complex SQL to execute - particularly if I need to rely on vendor specific stuff (SUM, IF, FROM_DAYS, TO_DAYS etc.) or if I’m using a UDF in MySQL say. I do quite a bit of work with financial companies and I’ve always ended up reverting to raw JDBC because everything else I’ve tried seems kind of painful.

    Back to top

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