BEA has completed the last set of OpenJPA code drops at the Apache Incubator, and it's now available for source download via Subversion. (Binary downloads will be available soon, according to BEA.) OpenJPA is a set of Java persistence Application Program Interfaces (APIs) that are based on the forthcoming Enterprise Java Beans 3.0 persistenace specification. It's based on BEA's Kodo product, acquired by BEA in late 2005, and the contribution to Apache represents fulfillment of a commitment BEA made in May 2006. OpenJPA implements the EJB3 specification, and the commercial Kodo release adds tooling for JDO as well as some scalability to the OpenJPA codebase. Changes made to OpenJPA under Apache will thus find their way to the Kodo product as well, which is meant to be the mapping engine used under WebLogic as well. OpenJPA itself has not passed the EJB3 TCK yet. It's hard to imagine that the TCK will not be applied soon; Kodo, based on the code released under the Apache OpenJPA project, has already passed the TCK tests. OpenJPA is also likely to be the persistence provider for Apache Geronimo in the future, so it's worth stressing as soon as possible, if you're interested. The Glassfish community also has mentioned supplying OpenJPA as an alternate JPA provider to the default reference implementation (TopLink Essentials), and Spring plans specific OpenJPA support soon as well.

Great news! I was wondering about an open source implementation of JPA.

... that are based on the forthcoming Enterprise Java Beans 3.0 persistenace specification...

forthcoming? Am I missing something here? EJB 3.0 is already released.

OpenJPA is also likely to be the persistence provider for Apache Geronimo in the future, so it's worth stressing as soon as possible, if you're interested. The Glassfish community also has mentioned supplying OpenJPA as an alternate JPA provider to the default reference implementation (TopLink Essentials), and Spring plans specific OpenJPA support soon as well.

This is good but I can't find any references to openJPA planned to be used in Spring, Geronimo or Glassfish (that doesn't mean it's not true). C http://ChintanRajyaguru.com

I presume BEA pays wages for this, but that it is now a revenue generating product. More a value add to stop slippage into JBoss/Hibernate? This is totally fine with me, I want an open JPA, ideally with some examples tied to spring and tomcat. But OpenJPA needs to have a future, a core team for the next 2 years. I'm just wondering on the plans for this? Is the current team staying with it as a labour of love (which is fine) or are BEA keeping the project propped up? I may have totally missed the real relationship of BEA to OpenJPA - in which case please do correct me, I'm not trying to spread FUD at all. Jonathan

Is the current team staying with it as a labour of love (which is fine) or are BEA keeping the project propped up?

I may have totally missed the real relationship of BEA to OpenJPA

Last year, BEA acquired SolarMetric, the makers of Kodo. Kodo has since been integrated into WebLogic Server as the EJB3 JPA persistence provider ( WebLogic EJB3 Tech Preview), and we're working hard on more integration with the server for the upcoming Java EE 5-compliant server release. So, in other words, Kodo is a key piece of BEA's EJB3 strategy, and as such, certainly has strong backing from BEA. The development team from SolarMetric (myself included) are among the initial committers on the OpenJPA project, and we're avoiding a fork in the Kodo codebase by building the commercial version of Kodo and, in turn, WebLogic, on top of the OpenJPA jars. Neelan Choksi (former SolarMetric president) goes into a bit more detail in his blog. Hopefully this clears things up a bit. -Patrick -- Patrick Linskey http://bea.com

oops, wrong subject on my last post (see above) Jonathan

This is good but I can't find any references to openJPA planned to be used in Spring, Geronimo or Glassfish (that doesn't mean it's not true).

Speaking on behalf of the Spring project, we are looking forward to working with the Open JPA committers and community, and it will absolutely be treated as a first-class citizen by Spring. We have someone scheduled to start on this next week. We've already done some work on Kodo integration, and validated that Spring's JPA support works with Kodo. Rod Johnson, Interface21, Spring from the Source

This is further excellent news. Now we have three capable open source ORM tools: Hibernate, TopLink Essentials, and now Open JPA. Developers have never had so much choice. We're putting a lot of effort in Spring 2.0 into ensuring that it's as easy as possible to switch between ORM tools, and easily evaluate the alternatives--for example, for different performance characteristics etc. Rgds Rod

This is further excellent news. Now we have three capable open source ORM tools: Hibernate, TopLink Essentials, and now Open JPA. Developers have never had so much choice.

Rod, think you meant to say three capable open source JPA tools because, of course, there are many other open source tools for other established ORM standards that are more than capable ;-) [and Spring has support for those too]

Rod, think you meant to say three capable open source JPA tools because, of course, there are many other open source tools for other established ORM standards that are more than capable ;-) [and Spring has support for those too]

Indeed I did. Spring has supported JDO since 1.0 and continues to do so.

This is further excellent news. Now we have three capable open source ORM tools: Hibernate, TopLink Essentials, and now Open JPA. Developers have never had so much choice.

Developers wandered in the dark, then a blinding light came and the road was clear: JPA. Come on, be serious. Where did you live before ? Not considering only open source choices we had (standard based solutions), in alphabetical order (surely incomplete list): Exadel (don't remeber the product name) IntelliBO JCredo JDOGenie (now Vanatec OpenAccess) JPOX (opensource) JRelay Kodo LiDO (now XCALIA) OpenAccess on sourceforge (opensource) Speedo (opensource) Guido.

Does this mean that the Spring 2.0 release will have to wait for Open JPA support? Or will it be added in 2.1 or such?

The Spring 2.0 release schedule is not driven by explicit OpenJPA support as mandatory feature. We will be releasing Spring 2.0 final with the present scope very soon now. That said, we are dedicated to supporting OpenJPA at the same level as TopLink Essentials and the Hibernate EntityManager, and to shipping it as part of our "-with-dependencies" download bundle. Depending on the state of OpenJPA at the time of the Spring 2.0 final release, we will either include specific support for it there already or will slip this into a subsequent 2.0.x release. Juergen

We're putting a lot of effort in Spring 2.0 into ensuring that it's as easy as possible to switch between ORM tools, and easily evaluate the alternatives--for example, for different performance characteristics etc.

Rgds
Rod

How's the work on a cross-JPA implementation of Criteria coming? Any plans to support something like Hibernate's Filters? I was very excited about the JPA spec until I saw it lacked these features that I depend on in Hibernate.

How's the work on a cross-JPA implementation of Criteria coming? Any plans to support something like Hibernate's Filters? I was very excited about the JPA spec until I saw it lacked these features that I depend on in Hibernate.

Yeah, same here. Filters are the one Hibernate feature that I miss from the JPA spec.

Uhm, wouldn't the best way to get these features into the Java Persistence products be a next version of the specification? I'm sure that more feedback will help to speed this up. Emmanuel Bernard just told me that ejb3-feedback at sun dot com is the right address for this.

Uhm, wouldn't the best way to get these features into the Java Persistence products be a next version of the specification? I'm sure that more feedback will help to speed this up. Emmanuel Bernard just told me that ejb3-feedback at sun dot com is the right address for this.

Well, that is a good way to get it, but it will take 18 months AT LEAST. Probably over 2 years.

Well, that is a good way to get it, but it will take 18 months AT LEAST. Probably over 2 years.

So put pressure on the vendors by requesting these features as part of their JPA solution. If the representatives of the vendors don't push for it on the EG we will see the same stagnation as with EJB 1/2. That just shouldn't happen again, now that we have a good base to work with. I've just finished comparing JPA and Hibernate in a book in detail and I agree that Hibernate criteria queries and data filters will be among the most frequently used vendor extensions. Some common subset should certainly be part of the next spec revision. (It's also obvious why they haven't been included in the first revision, I can imagine the endless discussions you can have about the best way to design a QBC API...)

Thanks - thats perfect. Good luck as well. Hopefully get time to use it soon :) Jonathan

This is good but I can't find any references to openJPA planned to be used in Spring, Geronimo or Glassfish (that doesn't mean it's not true).

I tried OpenJPA in GlassFish and guess what? It *works* just like so many other providers work in GlassFish. Just drop the OpenJPA jars in GlassFish lib folder and start using it. For details look at: http://weblogs.java.net/blog/ss141213/archive/2006/07/using_openjpa_a.html Interacting with developers in various support forums, I am seeing that developers are actually *exploring* various combinations of containers & providers. We have people using other providers in GlassFish and some actually trying to use our provider (TopLink Essential) in other containers. Good to see that the exerts group's effort in coming up with a *SPI* between provider and container paying off. -- Sahoo

This is most excellent news. Two things. Hibernate needs competition. So this is excellent timing. Now there is OpenJPA, TopLink Essentials and probably some more in the future. I use Hibernate with the JPA 'perspective' with a lot of pleasure in my projects but I don't always like their attitude and agenda. The TCK; it would be nice if Sun would open that. It would help the open source community big time. Right now when I submit a patch to say JBoss's EJB3 project or OpenJPA then I have to wait for someone inside JBoss or BEA to secretly run the TCK in private and wait for feedback. (I'm not contributing to these projects, this is just an example). I understand that they like to make some money but keeping the test kits closed is not helping the quality of open source projects. S.

The TCK; it would be nice if Sun would open that. It would help the open source community big time. Right now when I submit a patch to say JBoss's EJB3 project or OpenJPA then I have to wait for someone inside JBoss or BEA to secretly run the TCK in private and wait for feedback. (I'm not contributing to these projects, this is just an example). I understand that they like to make some money but keeping the test kits closed is not helping the quality of open source projects.

Agreed. It'd be nice if at least we (BEA) could maintain a machine somewhere that runs the JPA TCK in private on some CI server but then publishes the results for the world to see. Does anyone from Sun care to comment on the legality of such a setup? -Patrick -- Patrick Linskey http://bea.com

The TCK; it would be nice if Sun would open that. It would help the open source community big time. Right now when I submit a patch to say JBoss's EJB3 project or OpenJPA then I have to wait for someone inside JBoss or BEA to secretly run the TCK in private and wait for feedback. (I'm not contributing to these projects, this is just an example). I understand that they like to make some money but keeping the test kits closed is not helping the quality of open source projects.

Agreed. It'd be nice if at least we (BEA) could maintain a machine somewhere that runs the JPA TCK in private on some CI server but then publishes the results for the world to see. Does anyone from Sun care to comment on the legality of such a setup?

I'm sure that there's no problem with "Pass" and "Fail". :) Anything else encourages adoption of implementations that aren't complete as people decide "Hey, X doesn't work, but I don't need that anyway..." geir

The TCK; it would be nice if Sun would open that. It would help the open source community big time. Right now when I submit a patch to say JBoss's EJB3 project or OpenJPA then I have to wait for someone inside JBoss or BEA to secretly run the TCK in private and wait for feedback.

You mean like has been done for JSR 243 (JDO2) where the TCK, API, RI are all open source and everyone can run the TCK on any implementation, submit patches to the RI/TCK/API, and generally have an open standard ? That would be nice wouldn't it ? You could also mention that to get your hands on the "jpa.jar" you seemingly have to download a "JEE 5 SDK" ... all 132Mb of it (from jcp.org ... no download option for jpa.jar). Why ? Just to get my hands on 50Kb of jpa.jar? That is supposed to be runnable outside the container anyway. Not really making it easy for people here.

Or you could just go to the Glassfish project and just download the JPA implementation: https://glassfish.dev.java.net/downloads/persistence/JavaPersistence.html Not that Sun in any way makes it obvious you can do this and it requires half a dozen clicks to get from the Glassfish front page to that download page...

The ObjectWeb EasyBeans EJB3 container team will also ensure that OpenJPA can be used as entity manager. Currently, Hibernate EntityManager and Oracle TopLink Essentials can be plugged. The OpenJPA integration should be available in the M3 or M4 version of EasyBeans.