Find JSRs
Submit this Search

Ad Banner

JSRs: Java Specification Requests
JSR 338: JavaTM Persistence 2.1

Updates to the Original JSR Proposal

The following information has been updated from the original proposal.


2.18 Please provide a description of the business terms for the Specification, RI and TCK that will apply when this JSR is final.


2.13 Please describe the anticipated schedule for the development of this specification.

January 2011 Expert Group formed
Q3 2011 Early Draft
Q3 2012 Public Review
Q4 2012 Proposed Final Draft
Q1 2013 Final Release

The Spec Lead and Expert Group moved JSR 338 to JCP 2.8.

2.19 Please describe the communications channel you have established for the public to observe Expert Group deliberations, provide feedback, and view archives of all Expert Group communications.

The Expert Group will conduct business on jsr338-experts mailing list which is archived here:

2.20 What is the URL of the Issue Tracker that the public can read, and how does the public log issues in the Issue Tracker?
Registered users can post directly to the Issue Tracker.

2.21 Please provide the location of the publicly accessible document archive you have created for the Expert Group.

Original Java Specification Request (JSR)

Identification | Request | Contributions

Section 1. Identification

Submitting Member: Oracle

Name of Contact Person: Linda DeMichiel

E-Mail Address:

Telephone Number: +1 408 276 7057

Fax Number: +1 408 276 4185

Specification Lead: Linda DeMichiel

E-Mail Address:

Telephone Number: +1 408 276 7057

Fax Number: +1 408 276 4185

Initial Expert Group Membership:


Supporting this JSR:

akquinet tech@spree
Jeff Genender
Reza Rahman
Werner Keil

Section 2: Request

2.1 Please describe the proposed Specification:

The Java Persistence API is the Java API for the management of persistence and object/relational mapping in Java EE and Java SE environments. It provides an object/relational mapping facility for the Java application developer using a Java domain model to manage a relational database.

The purpose of the Java Persistence 2.1 specification is to extend the Java Persistence API to include additional features requested by the community.

Aspects that should be considered by the Expert Group for inclusion in this work include, but are not limited to, the following:

* Support for the use of custom types and transformation methods in object/relational mapping.

* Support for the use of "fetch groups" and/or "fetch plans" to provide further control over data that is fetched, detached, copied, and/or used in merging.

* Support for the specification of immutable attributes and readonly entities.

* Support for user-configurable naming strategies for use in O/R mapping and metamodel generation.

* More flexibility in the use of generated values; support for UUID generator type.

* Additional mapping metadata to provide better standardization for schema generation.

* Support for multitenancy.

* Additional event listeners and callback methods; availability of entity manager to callbacks.

* Methods for dirty detection.

* Improved ability to control persistence context synchronization.

* Additional unwrap methods to support use of vendor extensions.

* Support for dynamic definition of persistence unit, including object/relational mapping information.

* Extension of metamodel API to object/relational mapping information.

* Improvements to the Java Persistence query language and criteria APIs, including:

-- support for stored procedures;

-- support for additional built-in functions, and for the invocation of other database and vendor functions;

-- support for downcasting;

-- support for outer joins with ON conditions;

-- update and delete criteria queries;

-- support for mapping between JPQL queries and criteria queries.

* Improved support for the result type mapping of native queries.

* More flexible XML descriptors.

The goal of the Expert Group will be to assess these issues and identify and pursue directions for enhancement of the overall programming model and facilities of the Java Persistence API.

2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)

The target platforms are Java EE and Java SE.

2.3 The Executive Committees would like to ensure JSR submitters think about how their proposed technology relates to all of the Java platform editions. Please provide details here for which platform editions are being targeted by this JSR, and how this JSR has considered the relationship with the other platform editions.

The Java Persistence API is designed for both Java EE and Java SE platform environments. It is expected that Java Persistence 2.1 will be included as a required part of the Java Platform, Enterprise Edition version 7. Aligning the timeline of this JSR with that of Java EE 7 may therefore impact the scope of the Java Persistence 2.1 release. Features that may not be able to be addressed in Java Persistence 2.1 due to time constraints may become candidates for a future release.

2.4 Should this JSR be voted on by both Executive Committees?

No. It should be voted on by the Java SE / EE Executive Committee only.

2.5 What need of the Java community will be addressed by the proposed specification?

The goal of the proposed specification is to address the needs of the Java community by adding functionality to the Java Persistence API to address requests received from the members of the community.

2.6 Why isn't this need met by existing specifications?

See 2.5 above. The Java Persistence 2.1 release will augment the Java Persistence API with features that have been requested by the community and that are not present in the current release.

2.7 Please give a short description of the underlying technology or technologies:

See above.

2.8 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.)

The API Specification will continue to use the javax.persistence, javax.persistence.criteria, javax.persistence.metamodel, and javax.persistence.spi packages.

2.9 Does the proposed specification have any dependencies on specific operating systems, CPUs, or I/O devices that you know of?


2.10 Are there any security issues that cannot be addressed by the current security model?


2.11 Are there any internationalization or localization issues?


2.12 Are there any existing specifications that might be rendered obsolete, deprecated, or in need of revision as a result of this work?


2.13 Please describe the anticipated schedule for the development of this specification.

Jan 2011 Expert Group formed
Q3 2011 Early Draft
Q1 2012 Public Review
Q3 2012 Final Release

Note that this information has been updated since this original proposal.

2.14 Please describe the anticipated working model for the Expert Group working on developing this specification.

The primary means of communication will be email and conference calls. Face-to-face meetings will be scheduled if needed.

2.15 Provide detailed answers to the transparency checklist, making sure to include URLs as appropriate:

* The public can read the names of the people on the Expert Group.

Yes. This information will be available in all spec drafts and on the Update page of the JSR.

* The Expert Group business is regularly reported on a publicly readable alias.

We intend this to be the case. In addition, blogs will be used to keep the community updated on the progress of the JSR.

* The schedule for the JSR is publicly available, it's current, and I update it regularly.

This will be available on the JSR Update page.

* The public can read/write to a wiki for my JSR.

See the answers to other questions. It is likely that other means will be used to achieve similar functionality in addition to the JCP public forum for the JSR.

* I read and respond to posts on the discussion board for my JSR on

The discussion board will be used by the expert group. In the predecessor to this JSR (JSR-317), members of the community could engage in discussions with the expert group by means of posting to feedback aliases that channeled directly into the expert group. We intend to investigate means by which this functionality might be made available.

* There is an issue-tracker for my JSR that the public can read.

The issue-tracker for the JPA 2.1 reference implementation will be available to the public. Open issues in the specification drafts will be flagged there.

* I have spoken at conferences and events about my JSR recently.

Yes. It is expected that expert group members will participate in conferences and events and present updates on Java Persistence 2.1.

* I am using open-source processes for the development of the RI and/or TCK.

The Java Persistence RI is being developed under the open source EclipseLink project and is being made available through GlassFish.

* The Update tab for my JSR has links to and information about all public communication mechanisms and sites for the development of my JSR.

This will be the case.

2.16 Please describe how the RI and TCK will de delivered, i.e. as part of a profile or platform edition, or stand-alone, or both. Include version information for the profile or platform in your answer.

Oracle Corporation will deliver a Reference Implementation (RI) and Technology Compatibility Kit (TCK) available both stand-alone and as part of Java EE 7.

2.17 Please state the rationale if previous versions are available stand-alone and you are now proposing in 2.13 to only deliver RI and TCK as part of a profile or platform edition (See sections 1.1.5 and 1.1.6 of the JCP 2 document).


2.18 Please provide a description of the business terms for the Specification, RI and TCK that will apply when this JSR is final.

Note that this information has been updated from this original proposal.

Specification license
RI license
TCK license

NOTE that more information was added to the JSR when it moved to JCP 2.8. Find that additional information in the updates section of this page.


Section 3: Contributions

3.1 Please list any existing documents, specifications, or implementations that describe the technology. Please include links to the documents if they are publicly available.

Java Persistence API specification,

3.2 Explanation of how these items might be used as a starting point for the work.

The Java Persistence API as defined by JSR-317 will be the starting point for this work.

Experience with existing object/relational mapping implementations and vendor extensions to the Java Persistence API as defined by JSR-317 will be considered when evaluating new functionality.