Skip to main content

JavaOne Session: What's New in JPA 2.0

Posted by davidvc on May 10, 2007 at 12:30 AM PDT

I went to the Linda Lemichiel's session on what they're
planning JPA 2.0. I thought I'd summarize what I heard.
Note - at the end of the blog I provide an email address
you can use to provide feedback for what you want to see in JPA.
This is really important. JPA is a crucial technology for Java,
and we are all responsible for making sure it is delivering what
we need to build successful database applications using JPA.

Linda said that she expects the new JSR appearing quite shortly,
probably soon after everyone takes a breather from JavaOne.

What follows is a summary of the changes that are currently on
the table for JPA 2.0. The focus is on refining, fixing,
and improving portability.

More flexible modeling

Embeddable class support - The idea here is that it
should be possible to embed a class into another class without
mapping that class directly to a table. Instead it's stored
"embedded" inside another class as a column in the table.

Here is an example. Linda wanted to be very clear this was all
strawman syntax, and could very likely change as the
expert group refines the spec.

@Embeddable Person {
  String fname;
  String lname;
  @Embedded
  Address address;
}

Related to embedded classes is having the ability to factor out common
state using embedded super classes. The super class is not
mapped as a separate table, but in Java you can express the commonality
super class, but get to express commonality. One thing that needs
to be looked at more carefully is handling inheritance in embedded classes?

Ordered Lists - Many developers want the ordering applied
to a query to be persisted in the database. From the database
perspective, hardwiring ordering in the database is done by defining
an index column. This is something they're looking at.

Access Type - an "access type" is the process of defining
whether the provider uses fields or properties to access the
elements of a class. Currently a single access type applies to
complete entity hierarchy. The proposed change is to allow you
to specify this on a per-class basis, e.g. placing the
@AccessType(PROPERTY) annotation on an entity class.

Linda also suggesting doing this per field -- but this seems like
overkill to me.

Expanded O/R Mappping Functionality

Unidrectional one-to-many relationships using foreign key

You really don't want both ends of one-to-many relationship to have
to know about each other. Today you have to use a join table.
This change would allow you to specify the relationship on one
side only. This has a high likelihood of being added.

Inheritance mappings

The current supporte strategies are:

  • single table per hierarchy (all classes and subclasses in a single table)
  • joined subclass -- one table for superclass, each subclass in its
    own table. This is more normalized, but expensive for deep hierarchies.

  • Currently optional: table per concrete class. No superclass table.
    This is what legacy tables do. They're looking at adding this. The
    problem is what to do with polymorphic relationships.

Queries

Some current limitations:

  • SELECT clause too constrained. Only supports aggregate functions
  • Some unecessary restrictions on parameter usage - what about collections?
  • Queries are always polymorphic

Dynamic queries currently entail string construction. This is burdensome on
the app to build this. Criteria APIs allow "node-wise" query construction.

CriteriaQuery cq = em.createCriteriaQuery(Customer.class)
  .add(Restrictions.eq("status", "preferred")
  .add(Restrictions.eq("zip", "90210");

There are already existing criteria APIs and expression language APIs
available - Hibernate, OJB, Cayenne, TopLink, etc. They want to look
into using one of these rather than inventing their own. Linda said
this is one of the more ambitious tasks.

Standardized hints and properties

Currently configuration properties and hints are non-standard and specific
to each provide. Many could be standardized, such as standard
JDBC properties, connection pool properties, caching, cache size,
logging, DDL handling, etc.

Handling detached objects

The main issue with detached objects that they are looking at has to do with unfetched state and relationships. Detached objects often
have unfetched relationships. At point of detachment, the state that's
available is determined by the fetch elements (by default eager),
lazy fetching for ToMany relationships. The 1.0 spec does not say what happens when
you do access unfetched state. They'll be working on fixing this.

Extended persistence context

Allow entities to remain managed across multiple serial transactions.
Application-managed is always extended. It is up to the developer to manage the lifecycle of the persistence context. It is also up to the application to manage the association between a JTA transaction and persistence context. This is a common gotcha.

One way to solve this is
EntityManager detects it is in a transaction and registers with JTA
for notifications. But the EntityManager is not always created at the beginning o fa transaction, or you may have multiple active transactions, so the other way to do this is to register the EntityManager with a transaction using em.joinTransaction().

Container-managed transactions is for Java EE environments, and provides a much easier solution.

There is an open issue with conversational state, passivation and clustering. Basically right now it's not well defined what happens when conversational state contains an EntityManager and gets passivated and reconstituted, particularly on another instance of a cluster. This needs to get fixed.

Validation

JSR 303 on Bean Validation defines a metadata model and API for validation, for general use in SE and EE. They want to leverage this in JPA but it depends on timing. Some example validations include @Required, @Length(max=5) @Max(240), etc. They are also looking at supporting user-defined validation, e.g.

@AdequatelyCompensated
. When yo define these validation annotations, the provider can automatically check that these constraints are met. One question I had was when this validation takes place - when the attribute is modified, or when the transaction is committed? But I'm sure that will be made clear.

JPA 2.0 Roadmap

  • JSR to be posted shortly, after JavaOne recovery
  • EG formation in June
  • Align with Java EE 6 timing
  • Looking at implementing a first phase as a maintenance release (that would be nice).

How to give feedback

Send email to persistenceNoSpam-feature-requests@sun.com. This is functional today. When the EG is formed, the email will go to the EG.