Bindings, Platforms, and Innovation
This presentation focuses on the Internet and separating myth from fact, history from the future, and the mundane from the imaginative. Bob Frankston presents a vision of what could and should be.
News
Open JPA: A real competitor to Hibernate emerging
Posted by Floyd Marinescu on May 22, 2006 02:55 PM
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.
RelatedVendorContent
Open Source Middleware Reference Architecture Whitepaper
Velociti Partners Customer Survey
Business Benefits of Open Source SOA
Related Sponsor
The Adobe Flash Platform provides everything you need to develop applications, content and video across operating systems and devices.
JPAUtils?
by
Jason Carreira
Posted
May 22, 2006 1:58 PM
Re: JPAUtils?
by
Patrick Linskey
Posted
May 22, 2006 4:24 PM
Re: JPAUtils?
by
Rod Johnson
Posted
May 23, 2006 3:36 AM
Re: JPAUtils?
by
Rick Hightower
Posted
May 24, 2006 5:12 PM
Re: JPAUtils?
by
Rick Hightower
Posted
May 24, 2006 5:09 PM
WLS EJB3 persistence provider
by
Patrick Linskey
Posted
May 22, 2006 4:22 PM
Re: WLS EJB3 persistence provider
by
Alex Popescu
Posted
May 23, 2006 1:59 AM
At last, something to chip away at Hibernate
by
John Davies
Posted
May 22, 2006 8:29 PM
Monopolies
by
Gavin King
Posted
May 23, 2006 1:37 AM
Re: Monopolies
by
Marc Stock
Posted
May 23, 2006 1:38 PM
Re: Monopolies
by
Rick Hightower
Posted
May 24, 2006 5:14 PM
A real competitor to Hibernate *emerging*?
by
paul browne
Posted
May 23, 2006 3:29 AM
TopLink Essentials - JPA Compliant Today
by
Doug Clarke
Posted
May 23, 2006 10:13 AM
Re: TopLink Essentials - JPA Compliant Today
by
Doug Clarke
Posted
May 23, 2006 10:15 AM
Taking the bait....
by
Patrick Linskey
Posted
May 23, 2006 10:51 AM
Re: TopLink Essentials - JPA Compliant Today
by
Jason Carreira
Posted
May 23, 2006 12:18 PM
Re: TopLink Essentials - JPA Compliant Today
by
Floyd Marinescu
Posted
May 23, 2006 1:16 PM
Re: TopLink Essentials - JPA Compliant Today
by
Marc Stock
Posted
May 23, 2006 1:39 PM
Re: TopLink Essentials - JPA Compliant Today
by
Doug Clarke
Posted
May 23, 2006 2:44 PM
Re: TopLink Essentials - JPA Compliant Today
by
Rod Johnson
Posted
May 23, 2006 3:06 PM
Re: TopLink Essentials - JPA Compliant Today
by
Marc Stock
Posted
May 23, 2006 4:35 PM
Re: TopLink Essentials - JPA Compliant Today
by
Doug Clarke
Posted
May 23, 2006 4:38 PM
Re: TopLink Essentials - JPA Compliant Today
by
Marc Stock
Posted
May 24, 2006 10:06 AM
Re: TopLink Essentials - JPA Compliant Today
by
Thomas Risberg
Posted
May 24, 2006 2:25 PM
Re: TopLink Essentials - JPA Compliant Today
by
Marc Stock
Posted
May 25, 2006 9:12 AM
Re: TopLink Essentials - JPA Compliant Today
by
Doug Clarke
Posted
May 25, 2006 10:44 AM
Re: TopLink Essentials - JPA Compliant Today
by
Mark Richards
Posted
Jul 28, 2006 8:43 AM
-
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.
-
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 http://bea.com
-
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 http://bea.com
-
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-
-
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. :-)
-
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. -
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).
-
Patrick, Jason
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 -
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
-
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 http://bea.com -
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.
-
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 -
"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.
-
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.
-
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
-
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 :-) -
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?
-
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
-
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.
-
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.
-
This sounds like a great idea. I can't stand not having a Criteria API.
-
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.
-
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?
-
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.
-
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
-
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.
27 comments
Watch Thread Reply