Open JPA: A real competitor to Hibernate emerging
- Share
-
- |
Read later
My Reading List
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.
JPAUtils?
by
Jason Carreira
WLS EJB3 persistence provider
by
Patrick Linskey
-Patrick
--
Patrick Linskey
bea.com
Re: JPAUtils?
by
Patrick Linskey
-Patrick
--
Patrick Linskey
bea.com
At last, something to chip away at Hibernate
by
John Davies
Keep up the great work Patrick,
-John-
Monopolies
by
Gavin King
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
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
...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
(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
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.
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
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
Taking the bait....
by
Patrick Linskey
It is the reference implementation of JPA and as such is the first compliant implementation available.
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
Re: TopLink Essentials - JPA Compliant Today
by
Floyd Marinescu
As co-spec lead of JPA, Oracle contributed an open source edition of TopLink called "TopLink Essentials". 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.
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
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
Re: TopLink Essentials - JPA Compliant Today
by
Doug Clarke
Doug
Re: TopLink Essentials - JPA Compliant Today
by
Rod Johnson
TopLink Essentials is free and open source. It is currently being developed within GlassFish with Oracle and non-Oracle committers.
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
Re: TopLink Essentials - JPA Compliant Today
by
Doug Clarke
Doug
Re: TopLink Essentials - JPA Compliant Today
by
Marc Stock
Re: TopLink Essentials - JPA Compliant Today
by
Thomas Risberg
Re: JPAUtils?
by
Rick Hightower
Re: JPAUtils?
by
Rick Hightower
Cool.
Re: Monopolies
by
Rick Hightower
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
Re: TopLink Essentials - JPA Compliant Today
by
Doug Clarke
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
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.
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.
Educational Content
Tuning the Size of Your Thread Pool
Kirk Pepperdine May 23, 2013
Co-making Great Products
Jeff Patton May 22, 2013
Hello stranger!
You need to Register an InfoQ account or Login to post comments. But there's so much more behind being registered.Get the most out of the InfoQ experience.
Tell us what you think