E-mail    Print    Discuss    Blog

Adopting a Java Persistence Framework: Which, When, and What?

For developing new software systems, Object-Oriented Programming is undeniably the most widely used programming paradigm today. For commercial data persistence needs, the Relational Database Management System (RDBMS) is the most widely used system of choice. RDBMSes use a relational model, which is different than the domain object model of the software system. When your software system is developed using an object-oriented programming language and data persisted in RDBMS, a data persistence framework can be a very critical and important component of your application architecture to hide the underlying complexity of application data persistence.

Over the years, several persistence frameworks have evolved that help you manage your object-relational mapping and data persistence needs. Selecting a framework that suits your requirements is, however, not a trivial task, because several factors influence this decision. In this article, I intend to discuss some of the more widely used Java persistence frameworks against three fundamental criteria: Which, When, and What. In Which, I will introduce a framework; in When, I will discuss some of the scenarios when should you consider adopting it and some scenarios when should you look for an alternative; and finally, in What, I will discuss what benefits and what liabilities the framework has if you decide to adopt it. Let's begin with the following frameworks that are best known in the Java persistence landscape.

• Entity Enterprise Java Beans
• Java Persistence API
• Hibernate
• TopLink

Let me discuss these frameworks in more detail.

Entity Enterprise Java Beans

Enterprise JavaBeans (EJB) technology is a managed, server-side component architecture for the Java platform, Enterprise Edition (Java EE). In this definition, "managed" and "server-side" are the key terms. In EJB architecture, an application server manages the lifecycle of one or more deployed EJBs and provides common runtime services via an EJB container. Security, concurrency control, transactions, and persistence management are a few examples of container-provided services.

The EJB specification categorizes three types of enterprise beans: Session, Entity and Message Driven. Each type has some distinct characteristics and is used for different purposes. Since this article is about Java Persistence frameworks, let me briefly discuss the persistence aspect of the EJB architecture, which involves using Entity EJBs to manage the persistence requirements of your Enterprise Java application.

With EJBs, you can design your application such that an EJB represents an entity in your business domain model. For example, think about an Account entity of a commercial banking application. The Account entity bean will be deployed into the J2EE application server that will provide several runtime services to this entity bean via the EJB container. One such service is automatic persistence, which I will discuss in bit more detail.

Based on how the persistence is achieved, Entity EJBs are further classified into two categories: Bean-Managed Persistence (BMP) and Container-Managed Persistence(CMP). With BMP, the bean instance is responsible for persistence of its state, which is achieved by JDBC code. With Container-Managed Persistence, the EJB container provides the ability to automatically manage persistence of entity beans: saving the state to or loading the state from the underlying database as and when needed.

Now let's discuss some scenarios where you may want to adopt EJB framework in general and use CMP for data persistence in particular.

When to Consider Adopting EJB as Persistence Framework

1. The need for container-provided services is the first thing you should consider. If your application needs other container-provided services such as transaction management, security, and concurrency control in addition to persistence management, then the EJB framework is a better choice.

2. Resource requirement is another factor to consider. The EJB framework provides excellent scalability for demanding applications. This, however, comes with a price: intensive resource requirements, especially with the remote interface model. Consider adopting entity EJBs only if there is no resource restriction, to achieve the required level of performance.

3. A de facto framework is another factor in play. If you are doing some serious EE development based on the Java platform, then chances are that the EJB container is already available as part of your application server. "Why not use what is already available?" might be the first question asked in your architectural decision-making process. I consider this as a "political" advantage over other frameworks, because it is already available.

When to Consider an Alternative to EJB as Persistence Framework

1. The feature requirements of the persistence layer is the first factor that may prompt you to look for an alternative. If your application does not require every feature an EJB framework provides, then that is the first indication that you should look for an alternative.

2. Resource availability outweighing performance requirements is another situation in which you may want to look for another alternative. Although it provides excellent performance and scalability, the EJB framework is notorious for resource consumption. But the bottom line question is: do you really need this? A well-written data access object or the Hibernate framework will provide an excellent alternative to EJB in many situations.

3. A data source other than a relational database, although rare, would prevent you from using a container-managed persistence framework.

If you are already using or plan to use EJBs as your persistence framework, here are the benefits and liabilities you can expect.

What Are the Entity EJB Benefits?

1. The distributed component-based model makes it network-neutral--the EJB components can be deployed in the same JVM that serves the rest of the application, or in the JVM of an application server located in a different geographical location.

2. You will achieve excellent scalability: EJBs scale up nicely because the container can pool the instances, activating and passivating if necessary.

3. The EJB has been around for long enough to mature as a proven technology. Also, it has evolved to provide more useful services and features. For example, the timer service is one of my favorites; with it, you can schedule the execution of a job in specific intervals (such as nightly, weekly, or monthly). Another nice feature in EJB 3.0 is Java language metadata annotations support that eliminates all required interfaces for entity persistence, and enhancements in EJB's query language.

What Are the Entity EJB Liabilities?

1. The EJB architecture is non-trivial to learn and use. You should prepare to learn terms like remote interface, home interface, activation, passivation, and so on, most of which are applicable only to the EJB world.

2. The EJB architecture does not provide persistence independence. Since the classes are used in their own way within an EJB container, there is no easy way you can take EJB classes and use them in another framework.

3. Achieving an acceptable level of performance for entity beans has always been a challenge, especially in the remote interface model.

Java Persistence API

Right from the time when EJB technology became available for adoption, there has been general sense of skepticism on its usefulness in real-world applications. In my view, complexity and resource intensiveness are two of the most important reasons for this phenomenon. Consequently, simpler frameworks that have a smaller resource footprint, like Spring and Hibernate, appeared later than EJB but gained popularity more quickly. To address this, we have witnessed a major shift in the direction of EJB 3.0 specification from its predecessors. Created as part of JSR 220, this specification provides features like Plain Old Java Object (POJO) support, dependency injection, and annotations. A completely new set of APIs are now introduced as the Java Persistence API (JPA) to allow developers to manage relational data from Java EE (or even SE) applications. Further, Sun claims that the Java Persistence API draws some of the best ideas from the Hibernate, TopLink (both discussed later), JDO, and EJB frameworks.

Currently, the GlassFish project provides a reference implementation of the JPA as "TopLink Essentials," part of the GlassFish application server. You can find the JPA reference implementation on the GlassFish community page. Do not confuse TopLink Essentials with TopLink, which is the relational mapping tool currently owned by Oracle Corporation. I will discuss the TopLink framework later in this article.

Let's discuss some of the scenarios in which you should consider adopting JPA as your persistence framework.

When to Consider Adopting JPA as Persistence Framework

1. You prefer to adopt a standards-based framework with "nice to have" features from popular frameworks like Hibernate, TopLink, and EJB.

2. You need a lightweight persistence framework and don't necessarily need EJB's container-provided services.

3. You need a persistence framework that can be used in a standard or enterprise Java application.

When to Consider Alternatives to JPA

1. The version of Java that you are using determines if you can actually adopt JPA. JPA is part of the EJB 3.0 specification, which is part of the Java EE 5 release. If you are not up to Java EE 5, it is not possible to use JPA.

2. Your application requires services that JPA cannot provide, such as those provided by an EJB container, in which case you are pretty much tied to EJB.

Before ending discussions on this framework, let me list some benefits and liabilities of using JPA as your persistence framework.

What Are the JPA Benefits?

1. JPA is standards-based. More and more vendors are expected to offer the JPA implementation in the near future.

2. It offers the best features from Hibernate and TopLink.

3. It can be used with both Java SE and Java EE applications, with or without an EJB container.

What Are the JPA Liabilities?

1. Being fairly new, the JPA specification may go through significant evolution before becoming stable.

2. JPA is a specification instead of a product. You need a vendor to provide an implementation to get meaningful advantages from these standard-based APIs.

Hibernate

Hibernate is an object persistence framework that simplifies object-relational mapping between a Java application and an underlying relational database. It does so by providing transparent persistence of POJOs, working as a "mediator" layer to provide automatic persistence and loading of objects from a Java application to database tables. With Hibernate, saving object state to and loading object state from a database is as easy as calling methods in Java objects. You don't have to manage low-level database operations from your application code; the Hibernate framework takes care of all the intermediate steps for you.

Let's discuss some of the scenarios where you would consider adopting Hibernate as your persistence framework and those in which you should look for an alternative.

When to Use Hibernate as Your Persistence Framework

1. You are looking for a simple persistence framework that is easy to learn and use. You just need to understand a couple of mapping configuration files before you can actually start persisting your Java objects into the target database.

2. You are looking for a highly generic and flexible persistence framework. Hibernate is pretty flexible in terms of its usage: it can be used with or without an application server, and with or without relational database systems.

3. You don't want to pay acquisition and maintenance fees. Hibernate is open source and free.

The Hibernate framework is very compelling for adoption because it is simple and flexible, yet powerful. However, here are some scenarios when you may want to consider adopting a different framework.

When to Consider an Alternative Framework to Hibernate

1. You don't want yet another framework. Although simple, the Hibernate framework has its own learning curve, maintenance/upgrade cycle, and so forth.

2. You need container-provided services, such as those provided by EJB, in which case your choices are pretty much limited to EJB.

If you are using or plan to use Hibernate as your persistence framework, here are some of the benefits and liabilities.

What Are the Hibernate Benefits?

1. Hibernate is easy to learn and use. As I mentioned earlier, you just need to understand a couple of simple, self-described configuration files before before you can use it.

2. It is very flexible. You can use Hibernate in any application architecture that needs persistence service. You can use it in standard Java applications, in Enterprise Java applications with servlets, and/or with Enterprise Java Beans. It also integrates very nicely with the Spring framework.

3. It scales up pretty well, as it was designed from the ground up to work in a cluster environment. The performance of the latest version of Hibernate is also enhanced by techniques like lazy initialization and optimizing Java reflection via the CGLIB runtime byte code generation library.

What Are the Hibernate Liabilities?

1. Hibernate is another framework that has its own adoption and maintenance cycle.

2. Although active community support is available, sometimes the absence of a single vendor who specializes in the product makes it difficult to influence architectural reasons to adopt this framework.

TopLink

TopLink is another object-relational mapping framework for Java that provides a powerful and flexible framework for storing and loading Java objects to and from databases and XML documents. After several mergers and acquisitions (see a brief history on TopLink's Wikipedia page), TopLink has been part of the Oracle Fusion middleware since 2002.

In 2006, Oracle donated source code from the TopLink product and development resources to the java.net GlassFish project. This project was named TopLink Essentials and became the Java EE EJB 3.0 JPA reference implementation. It is a scaled-down version of the TopLink product from Oracle, missing some features such as cache synchronization between clustered applications, cache validation policy, and query cache. Also in 2007, Oracle donated the source code from the TopLink product and development resources to the open source EclipseLink project.

Here are some scenarios in which you may want to adopt TopLink as your persistence framework and some of the scenarios where you may want to look for alternatives.

When to Adopt TopLink as Persistence Framework

1. Although TopLink can be adapted to work with other software systems, it is a better choice if your software systems have a substantial presence of Oracle software products, because this creates a homogeneous software product suite from same vendor.

When to Consider Alternatives to TopLink as a Persistence Framework

1. You are a non-Oracle shop. If you have only a few software systems from Oracle, then you may have several other options more suited for your needs. This may be fairly typical for EE-based application servers because at the time of this writing, WebSphere, JBoss, and WebLogic are the top three leading application server vendors in terms of market share.

Let's finally evaluate some benefits and liabilities of adopting TopLink as your persistence framework.

What Are the TopLink Benefits?

1. TopLink is the ideal persistence framework choice if your chosen software lineup already has a substantial presence of Oracle products.

2. It is a pretty mature and time-tested framework, supported by Oracle.

3. Advanced features such as cache synchronization between clustered applications, cache validation policy, and query cache makes it suitable to adopt in applications that are clustered and require high performance.

What Are the TopLink Liabilities?

1. It is proprietary; its future direction is dictated by Oracle.

2. As with any new framework, it has its own learning curve.

Persistence Frameworks Selection Matrix

Before moving forward, let me summarize in the following table the frameworks discussed so far. In it you will see a general context (When), the framework you should consider (Which), and the benefits and liabilities you get (What). You should consider these as the starting points for the process of selecting persistence framework. Your final selection should be based on these and other application-specific requirements, if any.

Other Persistence Frameworks

Before summarizing, let me list some other persistence frameworks worth exploring before you actually adopt one. More detailed discussion on these frameworks is beyond the scope of the article.

• Castor: A free open source data binding framework.
• Kodo: An object-relational persistence engine from BEA Systems.
• Torque: An object-relational mapper for the Java platform, developed as an Apache DB project.
• iBatis: A data mapper framework that can be used with both Java and .NET applications.

Summary

It is obvious that which persistence framework you will adopt for your next Java application will be influenced by several factors such as features required, acquisition and maintenance costs, and non-functional requirements (its maintainability, performance, etc). Several proprietary and open source frameworks are now available, each with its own advantages (benefits) and liabilities (weaknesses).

In this article, I've presented some of the more popular Java persistence frameworks in terms of three criteria: which (defining the framework), when (when should you consider adopting and when should you look for an alternative), and what (what are the benefits and liabilities) of adopting it. The scenarios presented in this article are intended to assist you make a more informed decision before you actually select a framework for adoption. Therefore, you should adopt your next Java persistence framework based on the criteria discussed in this article in addition to other current and future needs specific to the application.

Resources

• A Comparative Study of Persistence Mechanisms for the Java Platform (PDF)
• JSR 220
• EJB product page
• Hibernate.org
• Java Persistence API
• TopLink Product page
• "BZ Research on Java EE Market Share Data"

Sharad Acharya has more than eight years of experience in the software engineering field in multiple business domains including supply chain, insurance, banking, and mortgage.

View all java.net Articles.

What did you think of this persistence framework comparison?

Showing messages 1 through 18 of 18.

• muro
  2008-07-13 15:16:37 nacctarum [Reply | View]
  
  mirc mırc mirc sohbet mirc download kameralı mirc mirc indir
  mirc kodları
  mirc indir mırc indir mirc nedir bedava mirc mirc download islami sohbet islami çet kelebek kelebek script kelebek chat kelebek script kameralı mirc mirc 2007 kameralı mirc kameralı sohbet kameralı chat chat çet çet yap yalova çet sohbet kanalı islami sohbet kanalları
  sohbet odaları sohbet odası şiir sohbet odaları chat odaları sevgili sevgili bul arkadaş arkadaş ara arkadaş bul arkadaşlık bedava sohbet arkadaşlık sitesi arkadaşlık siteleri partner sohbet et güzel mesajlar oto araba şarkı sözleri astroloji yemek tarifleri cep gazete gazeteler ibrahim hakkı bedava domain reklamsız bedava domain parça kontör sohbet radyo dinle radyolar indir bedava blog
  ücretsiz blog Buluşma

• My two cents
  2008-01-14 12:35:00 mikeploed [Reply | View]
  
  I think that this article does not do JPA justice. JPA is part of Enterprise JavaBeans (Version 3) and it is perfectly integrated with other container services.
  
  Another note on Hibernate and TopLink: Hibernate also comes with an optional query- and second level cache.
  
  I agree with the concerns regarding open source and support. But I must insist that for instance with Hibernate you are able to purchase a good support (Hibernate support by JBoss is really good if you pay for it). And, the most important point however, is that you get ways further since the code base is open source allowing you to debug into the source code. This gives you the opportunity to provide better tickets for the support team.
  
  I once worked with a really terrible JDO implementation that was packed with bugs, had an obfuscated code base and provided "error messages" that lied to you ... we had support but all we could tell them was "this and that does not work".
  
  BTW, all major JPA implementations are open source: Hibernate, OpenJPA and EclipseLink. In my eyes there is not one business case for a closed source JPA implementation.

• Torque
  2008-01-11 11:16:11 xaxi [Reply | View]
  
  Hi, the Torque link on this article is missing

• Comparing apples and oranges
  2008-01-04 09:57:00 lukin [Reply | View]
  
  In my opinion this article it total mess that compares apples and oranges e.g. standards and products. We may discuss product features, bells and whistles but when we speak of certain standard implementation.
  We may discuss standards as convenient or not, as containing principal disadvantages, etc
  
  Author of this articles have been trying to be nice for all speaking of things he did not really use as hard as needed to write such article.

• Clarifications from the author to some of the posts so far
  2008-01-02 21:56:38 sacharya [Reply | View]
  
  As the author of this article, I want to provide following clarifications to the posts so far.
  
  1. Regarding open source being liability: More people seems to disagree than agree when I state open source is liability. But my point is that some companies/managers do not feel the level of comfort while adopting open source because of the fact that there is not a single vendor that specializes the product and is responsible for it's customization, implementation and post implementation support. If the framework has some customization, it could be big liability later in the application life cycle especially at the time of system upgrades. I myself was involved in similar situation so I'm talking from my experience. For some people who are fine with what open source has to offer, it could be a fairly good choice. My point was to let the readers know that in some scenarios open source could be liability. For this reason, both open source and proprietary frameworks have their will their own market share and I believe that will continue to happen for foreseeable future.
  
  2. Confusion on the contents: There could have been some gap in the content but please note that I was trying to present a ten thousand foot view of the framework. Further, in this article I intend to discuss mainly the data access aspect of the frameworks so I included other aspects only if they relate to the aspect being discussed or felt have some significance. Bottom line--it is impossible to explain all the features of the frameworks in an article less than 3000 words.
  
  3. Regarding not listing other frameworks: So many other frameworks have been left out because of the length of article. I mentioned this in the article as well that only a few selected frameworks will be compared.
  
  4. JPA adoption and Java version: I intend to say that not in all scenarios JPA can be adopted and the version of Java SE is one of those. Thanks ddmarx for clarification on 2007-12-18 08:27:12 post
  
  Thanks everyone for their feedbacks.

• How about IBM PureQuery
  2007-12-31 01:49:57 sutinse [Reply | View]
  
  http://en.wikipedia.org/wiki/IBM_PureQuery

• Sometimes even the most lightweigh ORM framework is performance overkill
  2007-12-27 05:57:24 mcekovic [Reply | View]
  
  In some scenarios (real-time applications) event the most lightweight ORM framework is overkill for the performance, due to the very nature of the ORM paradigm. Don' forget that!

• Clarifying Points
  2007-12-21 15:40:22 ddmarx [Reply | View]
  
  The following points constitute my attempt to clarify some points that seem a little confusing in this article.

  EJB 2 and EJB 3 Principles Intermixed

  The article discusses Bean-Managed Persistence (BMP) with JDBC versus Container-Managed Persistence, but EJB 3.0 introduced an entirely new model for entity bean persistence. I must assume that the author is discussing EJB 2.x at this point.

  Discussion of the "remote interface model" also implies that the author is still talking about EJB 2.x and strengthens the assumption that most of the background information and the drawbacks listed in this article for Enterprise JavaBeans are actually for EJB 1.x and EJB 2.x rather than for EJB 3.0.

  It is a little confusing because the author references EJB 3.0's use of annotations to remove many of the coding difficulties commonly associated with previous incarnations of EJB, but then in the next sentence says, "The EJB architecture is non-trivial to learn and use" and lists some of the things commonly associated with previous EJB versions.

  The author also talks about EJBs not being usable in other frameworks, but EJB 3.0 uses "normal" Java classes which can be used in other frameworks as long as those frameworks ignore the JPA annotations on the normal Java class.

  JPA's Relationship to EJB 3

  JPA was created as part of the EJB 3 specification and is an inherent part of EJB 3. The specification creators made sure that conforming implementations of the JPA would support SE environments. The author mentions that JPA can work in both EJB and SE environments, but then goes on to state that Java EE 5 is required to use JPA. This is not true because SE does not have a dependency on EE in order to make JPA work.

  One "liability" of JPA listed in this article is the need for a vendor to provide a JPA limitation. The fact is that a "vendor" is required for all these implementations, including Hibernate (which is a "vendor" of a JPA implementation as well). Someone has to write the library or framework and the only question is if it is a standards-compliant library or framework or not. While some of the other covered frameworks "may" be standards-based (built on standards), the Java object-relational mapping persistence framework that is itself a standard is the Java Persistence API.

  There is a one-way dependency between EJB 3.0 and JPA. Any EJB 3.0 implementation should be expected to be heavily JPA-based, but the presence of JPA does not necessarily imply EJB because Java SE can use JPA.

  The Open Source Issue

  The author lists "open source" as a liability for Hibernate. This has bothered some others who have provided feedback, but I do know of managers and others who do indeed consider open source a liability. I generally like open source, but also realize that some types of open source actually are liabilities to certain types of commercial companies (such as GPL-licensed open source). Whether or not open source is a liability depends on the nature of the open source and the needs of the customers and stakeholders using the open source. That being said, Hibernate seems to be a well-accepted open source product with all the normal advantages of closed-source/commercial products such as available support, large user community, reasonable ultimate user license (LGPL versus ordinary GPL), etc.

  It is also worth noting that while "open source" may be categorized by some as a liability, others have exactly the opposite feeling and consider "closed source" (especially commercial closed-source requiring licensing fees) to be a liability.

• What about JDO
  2007-12-21 10:20:55 aldo_gg [Reply | View]
  
  JDO is live and kicking ass.
  
  Why don't you compare JPA with JDO
  JPA is just a subset of JDO
  
  See Jpox, Kodo, both support JDO 2 and JPA if you want to restrict yourself.
  
  Why Sun doesnt pick JDO instead of reinventing ugly EJB 2.0
  
  I am also a little confused about
  it is not the same JPA than EJB 3.0
• What about JDO
  2007-12-22 01:16:01 beders [Reply | View]
  
  Yeah, it is a shame JDO wasn't mentioned.
  By the time you kiddies struggled with EJB 2.0 persistence, JDO already had a better feature set than JPA has now.
  
  It's also a shame that the standardization process of JDO was such an ugly mess. Thank you Oracle, IBM, etc. :((
  
  Also too bad that it took WAY too much time to get a decent JDO implementation in the first place.
  
  Apart from that, JDO has it all:
  http://db.apache.org/jdo/jdo_v_jpa.html

• Too many errors!
  2007-12-20 03:03:55 dansiviter [Reply | View]
  
  Hmmm?! A fairly critical response to the article. Would it be possible for someone else, with knowledge of the topic, to read the articles before they're published? Should people who don't have a complete grasp of the subject area be allowed to publish articles? This one does have a fair amount of errors; too many to list, but here are my major concerns:
  
  > Open source does *not* mean it's a liability. Learning these tools is often far easier with open source communities and I've had bugs fixed in days rather that weeks.
  > I have been using Toplink Essentials on several different vendors DBs including IBM Informix, MySQL and Oracle without problems.
  > JPA works fine in vanilla JSE 5+.
  > Like JPA, Hibernate also does not need to be container managed; I've used it on simple Swing CRUD apps loads of times.
  > EJB what? 2.1? 3? EJB technology has changed much since the version 3 release (personally, coz of it's bad name would it have been better to rename it?). As mentioned by another commentator the line between 2.1 and 3 is blurred in this article. They're very different animals.
  
  Above all, the many of the arguments are correct but only if viewed from a particular angle; far too much ambiguity. I'd be happier if this article was removed or rewritten so not to misinform others.
• Too many errors!
  2008-01-04 07:53:22 caroljmcdonald [Reply | View]
  
  I agree, too many errors. It is not even worth talking about EJB 2.x CMP. One of the article resources referenced is from 2004 !

• Hibernate has terrible support
  2007-12-19 13:47:16 cowwoc [Reply | View]
  
  Open-source projects in general *are* a liability but Hibernate specifically has a serious support problem. Unless you pay the organization money you will find their support is terrible. Bug reports and feature requests will get closed with rude remarks. Posts on discussion forums get ignored. General (free) support is very hard to come by.
  
  Anyone considering using Hibernate should realize that 90% of the time it works like a charm, but you waste *days* fixing problems with the other 10%. This is how they make their money, as do many other open-source projects, by making the product harder to use and charging for support.
  
  The biggest ease-of-use concern with Hibernate are its exception messages. Sometimes you get misleading error messages that point you in the wrong direction. Other times you get messages that are so vague you have no idea what has gone wrong. If you file a RFE asking them to improve error reporting you will get a rude remark and the RFE will be closed promptly. Just my 2 cents.
  
  
  
  

• Open-source... (again)
  2007-12-18 18:42:26 asrgomes [Reply | View]
  
  While I think you have some points I don't agree with the plain statement that "open-source is liability". Actually, this a kind of misleading argument that may in fact add liability to your project. I worked in a project that decided to use Kodo instead of Hibernate just because LGPL was not friedly enough (liability, etc.). When I look at the code now I see how bad this decision was... Hibernate was far superior at that time and still is IMO. Maintenance is harder and tricky. Your mileage may vary though...

• "Open source" a liability?
  2007-12-18 16:30:41 mnasato [Reply | View]
  
  A confusing article.
  
  It mixes EJB 2.1 and EJB 3.0 concepts into the same section when they are very different beasts.
  
  It lists Hibernate and Toplink as alternatives to JPA when in fact they are JPA implementations, and doesn't mention other implementation such as OpenJPA.
  
  It says Hibernate suffers from "the absence of a single vendor" when in fact it is backed by JBoss / Red Hat.
  
  And it's the first time I see "open source" listed as a liability rather than a benefit!

• JPA Can Be Used in a Java SE Environment
  2007-12-18 08:27:12 ddmarx [Reply | View]
  
  The statement under the section "When to Consider Alternatives to JPA":
  
  

  
  The version of Java that you are using determines if you can actually adopt JPA. JPA is part of the EJB 3.0 specification, which is part of the Java EE 5 release. If you are not up to Java EE 5, it is not possible to use JPA.
  

  
  
  is not correct. While JPA was developed in conjunction with the EJB 3 specification, the specification developers went out of their way to ensure that it can be used with standard Java. However, it is true that the version of Java SE does matter as JPA uses annotations and other Java SE 5 features.

• Interesting conclusions
  2007-12-18 08:08:25 rabbe [Reply | View]
  
  I don't really agree with your statements regarding toplink as I have been able to use it with many DBMS systems including SQLServer, Derby and Oracle.
  
  Also, Hibernate and Toplink each provide JPA implementations however each can also be used independently of JPA. You should select JPA when you feel you may need to replace the backend persistence engine.

• Hibernate toplink and JPA
  2007-12-18 07:32:40 javaniraj [Reply | View]
  
  I thought that hibernate and top,link are the implementation of JPA.