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.