JavaOne 2010: Java Persistence API (JPA) 2.0 with EclipseLink

EclipseLink Project co-lead Doug Clarke presented the session "Java Persistence API (JPA) 2.0 with EclipseLink" presentation today at JavaOne 2010. I am a big fan of JPA, but I'm not going to be able to get to all of the JPA-related presentations due to competing sessions and I wanted to get a wide breadth of topics covered at this year's JavaOne. Clarke started his presentation by saying that he works on the reference implementation of JPA 2.0 (EclipseLink) and that this session will talk about some things EclipseLink provides outside of the specification.

The thing EclipseLink is known most for is its object-relational support, but Clarke pointed out that EclipseLink also supports Java/XML binding with JAXB and MOXy, Service Data Objects, and database web services (scrape data out of database and generate JAX-WS web service for web deployment).  Clarke described the various ways to access Eclipse Link (direct download, with GlassFish, and with Spring Framework were just some of the examples).

Clarke had a slide called "Understanding JPA" in which he showed the three pieces of JPA he commonly thinks of with "caching" joining them together.  He said they spend much of their time working on the caching.

Clarke said that he used annotations in the slides because they make it easier to see the obvious fields being mapped.  However, he also stated that significantly improved tooling has led many of his customers to return configuration back to XML.



Clarke introduced basics of JPA and then briefly introduced new features of JPA 2.0. He quickly moved onto EclipseLink custom annotations and other functionality beyond standard JPA. The idea, according to Clarke, is to allow people using these EclipseLink extensions to remain generally in the JPA space and they provide a eclipselink-orm.xml file for EclipseLink-specific configuration.


One extension EclipseLink provides is dynamic persistence that involves no Java classes, but instead relies solely on XML.  Clarke says that Oracle has used this with the Oracle ESB because they have no way of knowing in that context what object will need to be saved.


In talking about JPA mapping, Clarke reminded the audience that JPA uses the "configuration by exception" approach to mapping Java objects to relational database tables. In his example of a JPA entity class, he demonstrated the @Convert and @Converter annotations that are specific to EclipseLink.  He also mentioned the @PrivateOwned annotation.

When he talked about JPA querying, Clarke recommended using JPA named queries pattern and keeping named queries all in one place.  The argument is that any changes to objects can all be reflected in one place rather than needing to be found when scattered among the code.

EclipseLink offers extensions to JPA for querying.  This includes ability to query for read-only entities to improve performance and stored procedure/function support (including PL/SQL).  EclipseLink also does have some specific extensions to JPQL: FUNC for direct database function, TREAT AS downcasts child classes in inheritance hierarchy, and query keys can be defined.  EclipseLink extensions are also available to improve performance via explicit optimizations. EclipseLink provides query hints (an advertised "extension point" in the JPA specification) with the QueryHints class including QueryHints.FETCH (attribute joining) and QueryHints.BATCH.  Clarke showed different slides that demonstrated how to take advantage of these query hints to reduce 3N+1 (301) queries to 1, 2, or 4 queries for his 100 purchase order example.

Clarke introduced "partial entities with attribute groups" as a new feature in JPA 2.1. Attribute Grouping allows the developer to define what happens to each field in an object and not just relationships.  JPA has had FetchGroups for a while, but they are enhanced with JPA 2.1.  EclipseLink offers "two level loading": everything you specify in the FetchGroup and anything else needed later in that same thread.

EclipseLink simplifies stored procedure usage with @NamedStorageProcedureQuery and @NamedStoredProcedureQueries annotations. The only place this EclipseLink-specific knowledge is captured is in the configuration.

JPA 2.0 adds the Cache interface to have some control over shared cache. The interface allows the JPA community to start working with the vendor-specific caching mechanisms that cannot be brought together yet. The @Cacheable annotation can be used to set shared-cache-mode property (ALL, NONE, ENABLE_SELECTIVE, DISABLE_SELECTIVE, ).  EclipseLink has a default of cache set on.  EclipseLink has two-layer caching approach in which EntityManager has a transaction cache and the EntityManagerFactory has a shared cache.  EclipseLink's own @Cache annotation is used on a class level and configures shared cache handling of that entity; this does override the standard JPA caching setting.  @Cache allows cache type based on Java reference types: FULL, WEAK, SOFT/HARD WEAK, and NONE.  Can also specify cache size and expiration and disable shared caching with the @Cache annotation.

Clarke briefly mentioned EclipseLink's weaving. He introduced the @ChangeTracking annotation and its possible range of values.  Several EclipseLink interfaces allow for finer grain control of how sessions are serialized and cached.

Clarke began wrapping up his session with a slide titled "Performance Tuning Summary."

I am generally mostly interested in sticking to a specification's standard approaches as much as possible because that is, after all, one of the big reasons for using a specification-based product.  That being stated, there are times when for performance or other reasons, deviations must be used.  JPA has been designed to allow for extensions with reduced effect on the standard parts and EclipseLink's design seems to have kept this approach in mind as well.  Clarke's presentation was definitely focused on what EclipseLink provides as extensions to JPA (as he said it would at the beginning), but he also covered JPA basics and new features well in an effort to explain the EclipseLink extensions.

2008: Year of the Java Persistence API

It appears that one of the most popular themes in Java development in 2008 has been the Java Persistence API (JPA). I base this statement on the recent announcements that JPA-focused articles appeared in the Top Ten lists of articles for both Oracle Technology Network (OTN) and JavaLobby.

---

UPDATE (1 January 2009): Since the original posting of this article, the popularity of JPA in 2008 has been further proven by two JPA-related articles making JavaWorld's 2008 Top Ten and by a JPA-related article on EclipseLink making the ElipseZone Top Ten of 2008. See updates at end of this blog for additional details on these.

---

The article Looking Forward to JPA 2.0 (including Part 2) came in at #6 in the JavaLobby Top Ten Articles of 2008. This two-part article looks at what we can expect with JPA 2.0 (JSR 317). As a side note, EclipseLink will be the reference implementation of JPA 2.0.

My article Basic Java Persistence API Best Practices ended up being the fifth most popular article on Oracle Technology Network's Best of 2008: The Most Popular Tech Articles and How-Tos Published by OTN This Year.

It seems to me that it is more than coincidence that would explain two articles so highly focused on the Java Persistence API being listed in the Java-centric JavaLobby's Top Ten as well as the more general OTN Top Ten. The popularity of these articles is a reflection on the popularity and level of interest in the topic itself.

As further evidence of JPA's popularity in 2008, witness the series of articles in JavaWorld on JPA (Understanding the Java Persistence API, Part 1 and Understanding the Java Persistence API, Part 2) that appeared in early 2008. The fact that the editors at Oracle Technology Network, JavaLobby, and JavaWorld all published articles on JPA in 2008 is further evidence of the popularity of the topic. These editors strive to ascertain what is important to readers and prospective readers and it seems clear that JPA was one of those themes that was widely popular.

For very simple applications, I still prefer Spring JDBC. However, for more complicated (and more common) applications, I have found JPA-compliant implementations to be my object-relational mapping (ORM) tools of choice. It seems clear that 2008 has been a great year for interest in the Java Persistence API. This is not all that surprising when one considers the many advantages of JPA: same data access code across Java SE, Java EE web, and Java EE EJB; ability to switch between specification-compliant implementations, and ease-of-use with features such as configuration by exception (convention over configuration) and the ability to override in-code annotations with external XML configuration.

UPDATE (30 December 2008): An article introducing EclipseLink made the top ten list (#2) of the ten best articles in 2008 at EclipseZone.

UPDATE (1 January 2009): JavaWorld has put out its 2008 top ten (based on page views) and JPA is a focus of two of its top ten articles. Specifically, the article iBATIS, Hibernate, and JPA: Which is Right for You? was the fourth most popular article and Understanding JPA was the sixth most popular. A screen snapshot of the JavaWorld Top Ten of 2008 is shown next:

The Value of Named Parameters in JPA QL

In my article Basic Java Persistence API Best Practices, I wrote that because JPA is the result of good ideas from many previous technologies (Hibernate, JDBC, JDO, etc.), it follows that many of the best practices associated with these inspiring technologies can and should be applied to JPA. I used named and positional parameters as an example of this.

The interesting thing about JDBC's PreparedStatement is the fact that, out of the box, the JDBC standard PreparedStatement does not support named parameters. Rather, the PreparedStatement supports placeholders in the SQL syntax that are "populated" via set methods that provide the index of the ? being replaced (counting from left to right).

In order to make code more readable and easier to maintain, many people have tried to workaround the PreparedStatement's positional parameter binding approach. For example, I have seen cases where developers have made the numeric instances Java constants with names that are more readable than the numeral itself. More elegant solutions for using a named parameter type approach have been created to more easily enable "named" parameters. For example, Adam Crume introduces a class called NamedParameterStatement in the JavaWorld article Named Parameters for PreparedStatement. Perhaps even better known is the Spring Framework's support for the NamedParameterJdbcStatement (part of Spring's extensive JDBC support). Finally, Oracle has provided an Oracle-specific JDBC extension that allows named parameters to be specified and used with the OraclePreparedStatement when using an Oracle JDBC driver.

The rising popularity of being able to used named parameters in addition to ordinal parameters is also showcased by Oracle's support for named parameters in JDBC calls to PL/SQL and in IBM's Informix Dynamic Server (IDS).

The JPA contributors recognized the usefulness and desirability of named parameters and JPA Query Language has supported them since JPA's inception. JPA Query Language supports input parameters that are specified with a colon and the parameter name. Then, as demonstrated in the article Standardizing Java Persistence with the EJB3 Java Persistence API, this input parameter can be set by calling the Query.setParameter(---) method.

The JPA 1.0 specification covers named parameters in section 3.6.3. This section indicates how to use named parameters and points out that named parameters are only portable across JPA providers for JPA Query Language statements (not for native queries).

In the case of JPA, hindsight is 20/20. JPA was able to leverage named parameter binding in JPA Query Language statements from the beginning. This allows JPA developers to take advantage of a feature that has been proven to be beneficial many times over and has led to custom implementations when named parameter support is not built into the language or framework.

Highly Useful JPA-Related Blogs

I stated in a previous blog entry that I had to cut quite a bit of material from my first draft of the article Basic JPA Best Practices. In this blog entry, I want to discuss in more detail some of the blogs I have found that are most useful in my JPA development. While I was able to briefly mention the value of using such blogs in my article, I was not able to coverage them individually as well as I would have liked.

Blogs, by their nature, have certain advantages over other forms of communicating details on a specific technology. First, it is difficult to think of a faster way to communicate new information than a blog. Blog entries typically don't have the review process of a formal article and, in fact, are often even written more quickly by an author than an article would be. That, of course, is also the primary disadvantage of blogs -- they are not reviewed and their quality varies greatly from downright incorrect to highly valuable, informative, and leading edge.

Another advantage of the blog medium of communication is that it allows for highly focused coverage that appeals to a narrow audience that might not justify publication of a book or article. While books can be more detailed than articles, there is typically a significant period of time between a book's initial concept and its publication. In fact, it is this advantage of blogs (the ability to focus on narrow topics) that I am taking advantage of with this particular blog entry. I am focusing on some of the most useful JPA-related blogs I have encountered because I could not spend that much time on them in the article.

A final advantage of blogs over more traditional software development literature mediums is that many highly skilled, highly experienced, and knowledgeable developers may be more willing to write a blog entry or respond to a blog entry than they would be to take the time to write and publish an article or book.

Because of these advantages of the blog as a form of communication, it is useful for a JPA developer to read from and learn from the work of others as covered in JPA-related blogs. With these advantages established, it is time to look at some of the JPA-related blogs that I have found most useful in my own JPA work.

What Michael Bouschen's Blog lacks in terms of number of entries, it makes up for in terms of the unusually high quality of the entries. As of this writing, there are the only two entries as far as I can tell. Still, the two entries are useful enough to JPA developers to warrant this blog getting referenced in the article. The first entry, Using Relationships in the Java Persistence Query Language (July 2006), provides thorough but concise coverage of different types of joins that can be performed in JPA Query Language along with some other useful details about JPA Query Language relationships. I found the next blog entry, Java Persistence Query Return Types (April 2007), to be even more interesting and useful. This entry is also thorough but concise in its coverage of various methods of querying in JPA.

Wonseok Kim's Blog has many blog entries, including a large number on JPA, TopLink Essentials, and other JPA-related themes. There are too many entries to cover them individually here, but a good sample of the value provided in this blog can be found in the blog entry Understanding the Cache of of TopLink Essentials (GlassFish JPA). Of course, this will most interest users of TopLink Essentials as their JPA provider, but I imagine that is a fairly large group considering that it is the JPA 1.0 reference implementation and is bundled with GlassFish.

Sahoo's Blog is another valuable source of detailed JPA information. Sahoo has also posted several JPA-related entities, so I narrow my focus to two closely related examples. In the blog entries A javac Plugin to Manage Your persistence.xml and An annotation processor to update your persistence.xml during javac, Sahoo demonstrates how to use custom annotation processing to generate the persistence.xml file from in-source annotations in the Java code. This is similar to what I demonstrated for generating the orm.xml file (or equivalent multiple files) from in-source annotations in the OTN article Better JPA, Better JAXB, and Better Annotations Processing with Java SE 6.

There are, of course, many other blogs covering the Java Persistence API. Some (such as On Persistence [Shaun Smith], Java Persistence [Doug Clarke], and the EclipseLink Team Blog) are pretty much focused on JPA. Others (such as my blog, Chris Maki's blog, and the AMIS Technology Blog) have a more general software development focus, but occasionally feature JPA-specific blog entries.

JPA-related blog entries can provide many advantages such as timeliness, access to authoritative experts that might not wish to write a book or article, greater focus on details that don't warrant a full book or article, and other advantages associated with the so-called Web 2.0 social network. The one caveat is that not all blogs are created equal. The ones I have highlighted here are, in my opinion, of very high value and quality. However, especially with blogs you are not familiar with, it always makes sense to balance what you read in a blog entry with your own experience and with the experience of others as reflected in their blogs, articles, and books.

Basic JPA Best Practices Article Published

My article Basic Java Persistence API Best Practices was published on Oracle Technology Network (OTN) today. In this blog entry, I intend to provide a little background and extra information that I could not squeeze into the article itself.

As with most "best practices," the items discussed in this article are generally the "best" approach in my experience. That being said, almost nothing is always the better regardless of the circumstances and some practices closer to always being the best than are others. The focus of this article was on "basic" or relatively easy-to-implement practices that typically provide later benefits. In other words, I tried to cover JPA techniques and approaches that provide significant value for little extra effort or cost.

The focus on "basic" also meant that the article is largely targeted at developers just learning or starting to use JPA. More advanced JPA best practices are covered in JPA - Best Practices and Tips (2007 JavaOne Conference presentation referenced in my article), Java Persistence API - Portability Do's and Don'ts (another 2007 JavaOne Conference presentation referenced in my article), Java Persistence API: The Good, the Bad, and the Ugly, and the "under construction" EclipseLink FAQ on JPA Best Practices.

My original draft of this article was over twice as long as the final version. One of the technical editors pointed out (rightly) that the original version was too long. The final version is much easier to read quickly and meets my usual expectation that tighter and more concise articles are preferable to longer-winded articles. The only drawback to removing so much content is that I was forced to remove coverage of some things I thought were useful for developers just learning JPA, but which were not as significant as what did make the cut. I hope in future blog entries to cover some of these details that did not make the final article. In addition, I also plan to use this blog to provide additional background on why certain practices are "best" in my opinion and to provide source code examples to illustrate some of these best practices.

I mentioned/quoted/paraphrased Mike Keith a couple times in this article. His Colorado Software Summit 2007 presentations on JPA are both related to "JPA best practices" and are now available online. They are called JPA Portability: What You Should Know When Writing Portable JPA Applications and EJB 3.0 Puzzlers (focus is on JPA specifically rather than the more general EJB 3).

Two recent and highly detailed blog entries that look at subjects I touched upon in this article are Why Sometimes a Reference to an Entity Manager Inside JPA Entities is Needed and The Tense Relationship Between JPA, Enums, and Generics.

Finally, with JPA 2.0 getting more attention, there is much to look forward to in future Java Persistence API development.

EclipseLink Will be JPA 2.0 Reference Implementation

Oracle Corporation provided TopLink Essentials as the JPA 1.0 reference implementation. Two days ago (17 March 2008), it was announced that EclipseLink was selected as the JPA 2.0 reference implementation. The GlassFish announcement on this states that EclipseLink essentially includes most of Oracle's full-fledged TopLink product.

Because Oracle did provide TopLink Essentials as the Java Persistence API 1.0 reference implementation and because Oracle has been an ardent supporter of JPA, it is not too surprising that the Oracle-led EclipseLink project will be the JPA 2.0 reference implementation.

JPA and Spring Tutorials and References

The Spring Framework and the Java Persistence API (JPA) go well together. This blog entry is a simple list of tutorials and references that discuss use of JPA in conjunction with Spring.

• Using JPA in Spring
  http://www.chariotsolutions.com/slides/pdfs/spring-forward-2006-jpa-in-spring.pdf
• Using the Java Persistence API (JPA) with Spring 2.0
  http://java.sys-con.com/read/366275.htm
• Using JPA in Spring Without Referencing Spring
  http://blog.interface21.com/main/2006/08/07/using-jpa-in-spring-without-referencing-spring/
• Getting Started with JPA in Spring 2.0
  http://blog.interface21.com/main/2006/05/30/getting-started-with-jpa-in-spring-20/
  http://blog.springframework.com/markf/archives/2006/05/30/getting-started-with-jpa-in-spring-20/
• Using the Java Persistence API with Spring 2.0
  http://dev2dev.bea.com/pub/a/2006/03/jpa-spring-medrec.html
• Introduction to Spring 2 and JPA
  http://www.ibm.com/developerworks/edu/j-dw-java-spring2-i.html
• Data Access with Spring and Java
  http://java-x.blogspot.com/2006/12/data-access-with-spring-and-jpa.html
• Spring 2 and JPA Tutorials
  http://java-x.blogspot.com/2006/08/spring-2-and-jpa-tutorial.html
• Spring 2.5 Manual on JPA
  http://static.springframework.org/spring/docs/2.5.x/reference/orm.html#orm-jpa
• JPA and Spring DAOs
  http://www.newinstance.net/blog/?p=64
• The Hans Gruber Effect - Using Spring and Hibernate JPA
  http://bandaidprogramming.blogspot.com/2007/06/at-end-of-movie-die-hard-john-mcclane.html
• Oracle JPA and Spring
  http://gregpavlik.blogspot.com/2006/10/oracle-jpa-and-spring.html
• "Java Spring Tutorial" includes some JPA/Spring tutorials
  https://www.javacodegeeks.com/java-spring-tutorial

Sahoo's Javac Plugin for Persistence.xml Generation

In the article Better JPA, Better JAXB, and Better Annotations Processing with Java SE 6, I wrote about using JAXB to generate a Java Persistence API (JPA) object-relational mapping (ORM) file (usually called orm.xml) from in-source JPA annotations. In that article, I mentioned Sahoo's blog on using the Java 5 apt tool to generate a persistence.xml file. Sahoo has now posted a blog entry on A javac Plugin to Manage Your persistence.xml in which he demonstrates using javac in different contexts (directly, Maven, etc.) to generate a JPA persistence.xml file.

In a related blog, Sahoo lists some of his observations and experiences using the Java SE 6 annotation processor.

The persistence.xml file and the orm.xml (or one or more files fulfilling the same purpose) are the two main outside-of-code configuration files needed with JPA. The OTN article I cited above talks about generation of the orm.xml or equivalent file from in-source annotations and Sahoo's blogs cover creation of the persistence.xml file.