EclipseLink/Development/JPA

PAGE STATUS: DRAFT

The EclipseLink project has been chosen to deliver the JPA 2.0 reference implementation as part of JSR 317. This page provides a summary of the work planned and the current status.

JPA 2.0 Implementation Status

At present EclipseLink implements JPA 1.0 with advanced functionality made available through Persistence Unit Properties, Query Hints, a native ORM XML Schema, and native API. Some of the advanced 'extensions' align with what is being discussed for JPA 2.0.

Goals/Requirements

EclipseLink will introduce JPA 2.0 features with the following goals in mind:

1. Remain a compliant JPA 1.0 implementation during the development of 2.0 functionality. This is a major requirement since we are working towards a 1.0 release of EclipseLink which must be JPA 1.0 compliant.
   • This generally means that the JPA 1.0 persistence.jar could be on the classpath and the product should function as expected
2. Conform with the Eclipse IP process and rules. This means that the use of any updated persistence libraries and their source must come into the project through proper IP review procedures.
3. All new features involving changes to JPA's ORM-XML schema must be reflected in Eclipse-ORM.XML. This should be done in such a way that changes during the evolution of the specification are minimized.
4. Where possible any new features added for JPA 2.0 should also be available to users of the native EclipseLink ORM API and metadata. Accessibility through the native API can be limited to programmatic access and configuration.
   • EclipseLink users using JPA 1.0 will be able to access 2.0 preview functionality through native EclipseLink API or metadata

Types of Changes

The JPA 2.0 expert group is attempting to evolve this new specification to remain backwards compatible with JPA 1.0. The scope of its work will involve changes of various types with different effects on EclipseLink.

1. Metadata Changes
   1. New Annotations
   2. New structures in the persistence.xml XSD
   3. New structures in the ORM.XML XSD
2. API Changes
   1. New interfaces
   2. New methods on existing interfaces

Development Approach

In order to support JPA 2.0 new capabilities will be added to EclipseLink's core object-relational foundation. These features will then be exposed through new JPA 2.0 metadata and corresponding processing. The goal is to first make these available and functional in the native API so that all object-relational consumers have access and to minimize JPA only capabilities. JPA is definitely the priority but by making the features available internally we can more easily proceed with development of JPA 2.0 related functionality without requiring a final specification definition of the metadata or having to deal with too much flux as the metadata approach evolves in the expert group.

Metadata Changes

The following changes need to be handled keeping the backwards compatibility to JPA 1.0 goals in mind:

• New Annotations
• Modified Annotations
• Changes to the XML Schemas

JPA 2.0 Features

The following are features known to be required for JPA 2.0

EDR of JPA 2.0

Note that plumbing for some of these features already does exist in EclipseLink while other parts are going to require feature additions.

Feature to be completed:

• Extended Map support

Maps can have keys and values that can be any of basic, entity, or embedded. These are stored in a target table or join table.

• Derived Identifiers

Relationship mappings can be used as Id's or components of compound Id's directly without the need for separate primitive attributes.

• Nested embedding

ER 207823: Embedded objects can nest other embedded objects as well as being able to have relationships to entities.

• New collection mappings

Collections of embedded objects (aka Aggregate Collections) or of simple objects (Direct Collections)

• Pessimistic Locking Support

Adding support for EntityManager APIs and functionality for Pessimistic locking

• EntityManager API updates

Add support for the new EntityManager APIs.

• Ordered lists

Order of list is persisted to an "order column" when writes occur

• Orphan removal

When relationship is severed then the child is orphaned and hence deleted (other half of private-owned)

---

Features completed:

• uni-directional OneToMany without join table

Provide EclipseLink functionality to support a uni-directional OneToMany mapping that does not use a join table. This mapping will be similar to EclipseLink's current AggregateObjectMapping.

• Access Type

Provide support for configurable access type

JPA 1.0 Optional Features

-- No JPA 1.0 optional features that are not required in JPA 2.0 will be developed as part of this work.