EclipseLink/Development/JPA

STATUS: PROPOSAL --Doug 13:23, 17 December 2007 (EST)

This page presents the PROPOSED strategy for implementing JPA 2.0 within EclipseLink.

Developing the functionality required for JPA 2.0 will involve careful planning in order to maintain compatibility with JPA 1.0 interfaces and annotations.

Requirements

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.

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
   3. Changes to existing methods

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 to much flux as the metadata approach evolves in the expert group.

Metadata Changes

Q: How can new or extended annotations be leveraged in the metadata processing without breaking 1.0 compatibility or requiring the JPA 2.0 definitions on the classpath instead of JPA 1.0?

Q: Are there EclipseLink JPA extension annotations that exist today that will not be required in 2.0? What is the general strategy to handle these in EclipseLink 1.0?

API Changes

javax.persistence.EntityManager

Can we add API to org.eclipse.persistence.jpa.JpaEntityManager aligning with JPA 2.0 proposed API so that we can maintain support for JPA 1.0's EntityManager?

JPA 2.0 Features

the following are the features known to be required for JPA 2.0: