The open source persistence world may be facing some major competition this year as BEA is open sourcing a large part of the Kodo JPA container into the Apache OpenJPA project. Over the next 2-6 weeks they'll be getting a full TCK compliant OpenJPA implementation into the incubated project.
Patrick Linskey, who was a co-founder of SolarMetric and is an EJB expert group member will be the lead on the new project and BEA will commit about 10 people part time to it's development.
OpenJPA will be an enterprise grade JPA implementaiton suitable for production use. In addition to the JPA API it will also extend the JPA with features from Kodo including custom lock groups, dynamic fetch group configuration, custom mapping capabilities, Kodo save point capabilities, DB level save points, programmatic access to introspection of named queries, caching and even Kodo's built-in distributed cache implementation with hooks to plug in Tangosol's Coherence.
Some Kodo IP will be reserved for use in WebLogic Server and the commercial Kodo product, such as management and monitoring tools, more aggressive caching and scalability algorithms, deploy time and runtime features.
Going forward, Kodo 4.1 and WebLogic's JPA support will be built on top of Open JPA, not in parallel, as they don't want two separate code bases. One beneficial side effect of this is that OpenJPA will be be put through the same QA & documentation teams as any other commercial BEA product.
BEA's strategy is clearly aimed at Hibernate and JBoss. By open sourcing the proven and trusted Kodo project under Apache license with major ongoing support from BEA, OpenJPA will present the a viable alternative to Hibernate for mainstream adoption and users of OpenJPA will have an easy path to upgrade to Kodo, especially if they begin using the extension points.
It should be interesting to see the impact of this on the Geronimo project, which will almost certainly use OpenJPA to provide JPA for Geronimo (infact there are Geronimo committers on the initial commit list. Another side effect may be the addition of TopLink to the race, which already has a portion open sourced as part of Glassfish but is not being pushed by Oracle as a viable standalone project yet. Hibernate has earned a virtual monopoly for itself and now the rest of the industry is trying to catch up.
Patrick Linskey, who was a co-founder of SolarMetric and is an EJB expert group member will be the lead on the new project and BEA will commit about 10 people part time to it's development.
OpenJPA will be an enterprise grade JPA implementaiton suitable for production use. In addition to the JPA API it will also extend the JPA with features from Kodo including custom lock groups, dynamic fetch group configuration, custom mapping capabilities, Kodo save point capabilities, DB level save points, programmatic access to introspection of named queries, caching and even Kodo's built-in distributed cache implementation with hooks to plug in Tangosol's Coherence.
Some Kodo IP will be reserved for use in WebLogic Server and the commercial Kodo product, such as management and monitoring tools, more aggressive caching and scalability algorithms, deploy time and runtime features.
Going forward, Kodo 4.1 and WebLogic's JPA support will be built on top of Open JPA, not in parallel, as they don't want two separate code bases. One beneficial side effect of this is that OpenJPA will be be put through the same QA & documentation teams as any other commercial BEA product.
BEA's strategy is clearly aimed at Hibernate and JBoss. By open sourcing the proven and trusted Kodo project under Apache license with major ongoing support from BEA, OpenJPA will present the a viable alternative to Hibernate for mainstream adoption and users of OpenJPA will have an easy path to upgrade to Kodo, especially if they begin using the extension points.
It should be interesting to see the impact of this on the Geronimo project, which will almost certainly use OpenJPA to provide JPA for Geronimo (infact there are Geronimo committers on the initial commit list. Another side effect may be the addition of TopLink to the race, which already has a portion open sourced as part of Glassfish but is not being pushed by Oracle as a viable standalone project yet. Hibernate has earned a virtual monopoly for itself and now the rest of the industry is trying to catch up.
Community comments
JPAUtils?
by Jason Carreira,
Re: JPAUtils?
by Patrick Linskey,
Re: JPAUtils?
by Rod Johnson,
Re: JPAUtils?
by Rick Hightower,
Re: JPAUtils?
by Rick Hightower,
WLS EJB3 persistence provider
by Patrick Linskey,
Re: WLS EJB3 persistence provider
by Alex Popescu,
At last, something to chip away at Hibernate
by John Davies,
Monopolies
by Gavin King,
Re: Monopolies
by Marc Stock,
Re: Monopolies
by Rick Hightower,
A real competitor to Hibernate *emerging*?
by paul browne,
TopLink Essentials - JPA Compliant Today
by Doug Clarke,
Re: TopLink Essentials - JPA Compliant Today
by Doug Clarke,
Taking the bait....
by Patrick Linskey,
Re: TopLink Essentials - JPA Compliant Today
by Jason Carreira,
Re: TopLink Essentials - JPA Compliant Today
by Floyd Marinescu,
Re: TopLink Essentials - JPA Compliant Today
by Marc Stock,
Re: TopLink Essentials - JPA Compliant Today
by Doug Clarke,
Re: TopLink Essentials - JPA Compliant Today
by Rod Johnson,
Re: TopLink Essentials - JPA Compliant Today
by Marc Stock,
Re: TopLink Essentials - JPA Compliant Today
by Doug Clarke,
Re: TopLink Essentials - JPA Compliant Today
by Marc Stock,
Re: TopLink Essentials - JPA Compliant Today
by Thomas Risberg,
Re: TopLink Essentials - JPA Compliant Today
by Marc Stock,
Re: TopLink Essentials - JPA Compliant Today
by Doug Clarke,
Re: TopLink Essentials - JPA Compliant Today
by Mark Richards,
JPAUtils?
by Jason Carreira,
Your message is awaiting moderation. Thank you for participating in the discussion.
There's been some talk of creating another opensource project to build on the JPA spec and add things like a Criteria API and filters, which are both part of Hibernate's non-JPA API. This project could include JPA product specific implementations of base interfaces for these features, or could try to dynamically add to the queries in a JPA-spec neutral way.
WLS EJB3 persistence provider
by Patrick Linskey,
Your message is awaiting moderation. Thank you for participating in the discussion.
Additionally, OpenJPA will be bundled (via Kodo) with the upcoming Java EE-compliant WebLogic Server release, as the default EJB3 persistence provider. You can get early access to this upcoming release in the form of the WebLogic Server EJB3 Technology Preview.
-Patrick
--
Patrick Linskey
bea.com
Re: JPAUtils?
by Patrick Linskey,
Your message is awaiting moderation. Thank you for participating in the discussion.
I think it'd be cool to get a project going somewhere that can put pressure on the JPA2.0 team to get things rolling. Aside from things like a programmatic way of building JPQL, such a beast would be a great location for all sorts of common behavior (such as pessimistic locking support and cache control, for starters) that most JPA impls support but aren't yet defined in the spec.
-Patrick
--
Patrick Linskey
bea.com
At last, something to chip away at Hibernate
by John Davies,
Your message is awaiting moderation. Thank you for participating in the discussion.
OpenJPA get my vote, I will be pushing hard to get my team looking at this as a viable alternative to Hibernate.
Keep up the great work Patrick,
-John-
Monopolies
by Gavin King,
Your message is awaiting moderation. Thank you for participating in the discussion.
Hibernate has earned a virtual monopoly for itself and now the rest of the industry is trying to catch up.
Unfortunately, monopolies - and especially monopolies that are not based on open standards - tend to strangle the growth of a marketplace. The reason we at JBoss pushed so long and hard to make JPA a reality was because we saw that a standard blessed by the EJB brand and deeply integrated into the Java EE programming model would expand the total size of the market for ORM technology. (At the time we had pick between two different paths to reaching a persistence standard. I believe we chose correctly, and that this choice will be clearly vindicated over the next couple of years.)
So, while the existence of this new standard certainly gives a leg up to competition - as we knew it would - it also gives a leg up to Hibernate. All of us benefit from a larger market place, even if our relative market share falls slightly. So we expect to see further massive growth in Hibernate adoption. In fact, without JPA, I believe that Hibernate adoption would have begun to slow about a year ago. But what has actually happened is that - on the back of the EJB brand - our install base has continued to grow at a fast pace, at least as measured by our website traffic, and growth of our paying customer base.
I am sorely disappointed that this pattern of adoption via open source, followed by mass adoption via standards has not been picked up by other widely used open source projects. If this pattern became the norm, the community would benefit massively, as would the open source trailblazers. Unfortunately, it is always easy to fall into the trap of trying to protect a monopoly to the detriment of your users, the community and yourself. We believe strongly that this is the wrong path, and not the path for Hibernate or JBoss.
Of course, Hibernate remains the most richly featured (open source or otherwise) ORM solution in existence. :-)
Re: WLS EJB3 persistence provider
by Alex Popescu,
Your message is awaiting moderation. Thank you for participating in the discussion.
...which is further linked with the initiative of BEA and I21: Spring support for JEE 5 Programming Model
./alex
--
:Architect of InfoQ.com:
.w( the_mindstorm )p.
A real competitor to Hibernate *emerging*?
by paul browne,
Your message is awaiting moderation. Thank you for participating in the discussion.
Mercenary Java consultant that I am , I'll wait until OpenJPA is mature (has finished Emerging) before evaluating it. Until then , Hibernate will do me just fine.
(I'm half hoping that the OpenJPA team will force me to eat my words within the next 12 months. Either way , the Java community is in a win-win situation).
Re: JPAUtils?
by Rod Johnson,
Your message is awaiting moderation. Thank you for participating in the discussion.
Patrick, Jason
We are planning to do just this as part of Spring, which is a natural place for it, as many folk traditionally use their ORM tools via Spring for a variety of reasons.
In the Spring 2.0 release (final in the next month) we are adding a full JPA container (supporting the EE, as opposed to the SE) contract, and are putting a lot of emphasis on allowing easy portability between providers. I.e. Spring will do the work of figuring out what properties need to go up to the container for common tasks, meaning people don't have to waste time digging into reference docs if they just want to try their JPA-based code in a different provider as part of a benchmark or just for curiosity. Spring will also offer a powerful integration testing framework (like its existing org.springframework.test package) that will make JPA-based code, with any provider, very easy to test with no special setup or agent required.
In Spring 2.1 we will move further in the direction of adding some of the methods that should really be in the spec--looking at all three major providers, it's pretty clear that there's a lot of commonality at EntityManager and EntityManagerFactory level. We hope to work with the ORM vendors and the community to help capture this. Ultimately it would be great to have features like query by example and criteria or builder queries, and this may well be feasible. I'm confident that within a couple of months, Spring will clearly be the best environment in which to use JPA.
As future versions of the JPA spec (hopefully) move in this direction, we will deprecate our own versions and help people move forward to comply with the spec.
We think that JPA is great news, and will be ensuring that it's easy to use and that there are no gotchas in migrating from proprietary APIs.
Rgds
Rod
TopLink Essentials - JPA Compliant Today
by Doug Clarke,
Your message is awaiting moderation. Thank you for participating in the discussion.
As co-spec lead of JPA, Oracle contributed an open source edition of TopLink called "TopLink Essentials". It is the reference implementation of JPA and as such is the first compliant implementation available. It is a commercial quality implementation sharing the same core ORM engine with our Oracle TopLink product. It is a very viable standalone open source project that Oracle is fully committed to.
If you would like to learn more or download TopLink Essentials and try it out for yourself please check our out JPA site at:
OTN.ORCALE.COM/JPA
Doug Clarke
Product Manager, Oracle TopLink
Re: TopLink Essentials - JPA Compliant Today
by Doug Clarke,
Your message is awaiting moderation. Thank you for participating in the discussion.
OTN.ORACLE.COM/JPA
Taking the bait....
by Patrick Linskey,
Your message is awaiting moderation. Thank you for participating in the discussion.
Kodo 4.0 passed the TCK as well, sometime around the 12th of May or so. I guess that not being the RI, we implicitly cannot be the first, but passing the TCK within a couple days of it becoming available is good enough for me.
-Patrick
--
Patrick Linskey
bea.com
Re: TopLink Essentials - JPA Compliant Today
by Jason Carreira,
Your message is awaiting moderation. Thank you for participating in the discussion.
True, TopLink has been there, but you've suffered from being too much a part of GlassFish and not being available separately... Even if it IS available separately, I haven't heard about it, and I read a lot of news, so the message isn't out there.
Re: TopLink Essentials - JPA Compliant Today
by Floyd Marinescu,
Your message is awaiting moderation. Thank you for participating in the discussion.
Doug, TopLink is a great product so I hope Oracle does position TopLink Essentials as a real standalone product and a third alternative in the open source persistence world. I don't think having the project live on a sub-page of the OTN, without the typical window dressing of an open source project is the best approach to gain more adoption however. Perhaps Codehaus or OpenSymphony would be interested in being a home for it.
Floyd
Re: Monopolies
by Marc Stock,
Your message is awaiting moderation. Thank you for participating in the discussion.
"Of course, Hibernate remains the most richly featured (open source or otherwise) ORM solution in existence.:-)"
I disagree with this statement. Although you had a smiley at the end, I'm not sure if you're being serious. In any event, I just want to say that I've used Toplink before for actual commercial development and found it to be a very powerful and capable ORM tool that works very well even in complex clustered environments. It's unfortunate that Oracle hasn't open sourced it or made it free at least like Weblogic just did with OpenJPA. I think the enhanced competition in the free ORM space would be great.
Re: TopLink Essentials - JPA Compliant Today
by Marc Stock,
Your message is awaiting moderation. Thank you for participating in the discussion.
For the love of God, make it free please. TopLink is a great product that unfortunately just doesn't get used because of the cost.
Re: TopLink Essentials - JPA Compliant Today
by Doug Clarke,
Your message is awaiting moderation. Thank you for participating in the discussion.
TopLink Essentials is free and open source. It is currently being developed within GlassFish with Oracle and non-Oracle committers. The page provided on OTN is to simplify access it and allow us to publicize additional material to help developers make use of it.
Doug
Re: TopLink Essentials - JPA Compliant Today
by Rod Johnson,
Your message is awaiting moderation. Thank you for participating in the discussion.
Yep. Not one, but two more open source persistence solutions to choose from in the last few months. Developers have never had it so good :-)
Re: TopLink Essentials - JPA Compliant Today
by Marc Stock,
Your message is awaiting moderation. Thank you for participating in the discussion.
My understanding is that essentials is just a piece of TopLink. I want the whole enchilada. Also, can you even use essentials outside of GlassFish?
Re: TopLink Essentials - JPA Compliant Today
by Doug Clarke,
Your message is awaiting moderation. Thank you for participating in the discussion.
Yes, TopLink Essentials can be used outside of GlassFish. The JPA specification requires support for Java EE and Java SE. There is a tutorial and ready to run example published on our site showing the usage of TopLink Essentials in a Tomcat web application.
Doug
Re: TopLink Essentials - JPA Compliant Today
by Marc Stock,
Your message is awaiting moderation. Thank you for participating in the discussion.
I TopLink Essentials only supports EJB entity beans, correct? If I don't want to use EJBs, it's worthless. The entire TopLink product should have the same license as essentials.
Re: TopLink Essentials - JPA Compliant Today
by Thomas Risberg,
Your message is awaiting moderation. Thank you for participating in the discussion.
The EJBs supported by Toplink Essentials or any other JPA implementation are basically POJOs - other than the optional annotations there is no dependency on any EJB technology. Works great in a J2SE environment. Very easy to swap one implementation for another one as well. I just ran some tests using Toplink Essentials, Hibernate 3.2CR1 and Kodo 4.0 - same codebase, just switched jars and persistence.xml.
Re: JPAUtils?
by Rick Hightower,
Your message is awaiting moderation. Thank you for participating in the discussion.
This sounds like a great idea. I can't stand not having a Criteria API.
Re: JPAUtils?
by Rick Hightower,
Your message is awaiting moderation. Thank you for participating in the discussion.
RE: Ultimately it would be great to have features like query by example and criteria or builder queries, and this may well be feasible.
Cool.
Re: Monopolies
by Rick Hightower,
Your message is awaiting moderation. Thank you for participating in the discussion.
It is one thing to say Gavin is wrong. It is another to prove he is wrong. What is so great about TopLink?
I have a dear friend who has used both and does not like TopLink. I have not used TopLink so don't know.
If KODO, why KODO?
If TopLink, why TopLink?
Re: TopLink Essentials - JPA Compliant Today
by Marc Stock,
Your message is awaiting moderation. Thank you for participating in the discussion.
The point I was trying to make was that I want TopLink to handle my persistence but without using EJB entity beans. Thanks for the info on your testing though, that's good stuff to know.
Re: TopLink Essentials - JPA Compliant Today
by Doug Clarke,
Your message is awaiting moderation. Thank you for participating in the discussion.
Just to be clear.
There are no EJB entity beans in the JPA specification. They are simply POJOs with either XML and/or annotation ORM metadata. To avoid confusion with previous versions of the EJB specification these are simply called entities.
Using TopLink Essentials (or any other JPA implementation) does not require the use of EJBs or an EJB container.
Doug
Re: TopLink Essentials - JPA Compliant Today
by Mark Richards,
Your message is awaiting moderation. Thank you for participating in the discussion.
It is truly unfortunate that the spec team chose to use the work "entity" to describe the persistence mapped pojo's. I had a feeling this would cause some confusion. JPA Entities are not EJB's. They are regular POJO's using annotations or xml to describe the mappings. JPA entity objects can be used as regular pojo transfer objects as well.