BEA Systems has announced that it will open source a significant portion of BEA Kodo, its persistence engine, under the name Open JPA. BEA acquired Kodo as part of its purchase of SolarMetric, Inc. in November 2005. Open JPA will implement the persistence architecture described in the EJB 3.0 specification (and implements the early draft specification today.) Open JPA is expected to be available in the first half of 2006. BEA Kodo - the source for Open JPA - is available today for free evaluation and purchase.

BEA will offer a commercial implementation and tooling as well as mission critical support for those who require it.

The announcement is another aspect of BEA's commitment to enabling developers to utilize both commercial software and open source projects. This "blended" approach allows developers to mix and match the best features from each solution while maintaining a seamless platform for teams to develop, deploy and administer their applications and services. This is becoming increasingly important for those creating next-generation service oriented architectures (SOA), and is reflected by BEA's validation of frameworks such as Spring.

Resources:

• The Press Release from BEA.com

BEA Systems has announced that it will open source a significant portion of BEA Kodo [..] Open JPA will implement the persistence architecture described in the EJB 3.0 specification (and implements the early draft specification today.)

KODO supports both JDO2 and EJB3, and has proven to have quite a few optimizations that put it well ahead of some of the competing implementations in this space. How much of KODO is actually being open-sourced? What's the license? Where's the URL? ;-)

Peace,

Cameron Purdy
Tangosol Coherence: The Java Data Grid

What's the license? Where's the URL?

Nothing to be seen on the BEA or Kodo sites. Must be another rumour ...

Nothing to be seen on the BEA or Kodo sites. Must be another rumour ...

It's on BEAS's site in the press releases section, although it doesn't give any more information than the little blurb here on TSS.

http://www.bea.com/framework.jsp?CNT=pr01631.htm&FP=/content/news_events/press_releases/2006

What's the license? Where's the URL?

Nothing to be seen on the BEA or Kodo sites. Must be another rumour ...

Not a rumour. I added the link to the press release as soon as I got the link; I posted the news as soon as I was allowed to.

BEA Systems has announced that it will open source a significant portion of BEA Kodo [..] Open JPA will implement the persistence architecture described in the EJB 3.0 specification (and implements the early draft specification today.)

KODO supports both JDO2 and EJB3, and has proven to have quite a few optimizations that put it well ahead of some of the competing implementations in this space. How much of KODO is actually being open-sourced? What's the license? Where's the URL? ;-)Peace,Cameron PurdyTangosol Coherence: The Java Data Grid

Actually, Kodo doesn't fully support either JDO 2.0 or EJB 3.0 yet. What I really want to know is what is the future, if any, for JDO 2.0 under Kodo? Is this being open sourced as well? Some of us would be making major decisions on which persistence architecture to use based on the answers.

Great news! Competition on open source JPA is a good thing.

Any idea what the license is gonna be?

James
LogicBlaze
Open Source SOA

Great news! Competition on open source JPA is a good thing.

Absolutely definitely.

And we would not have this robust competition if it was not for *standards*. Remember that next time you hear someone questioning the value of the JCP. ;)

What a good news! Kodo is universally known one of best OR Mapping tools for completeness, documentation and performance.

Congratulations to Patrick Linskey, Solarmetric's staff and, why not, BEA.

bye,
Luca Garulli
Blogging on: http://zion-city.blogspot.com
www.Pro-Netics.com (member of Orixo.com - The XML business alliance)
www.OrienTechnologies.com - Light ODBMS, All in one JDO solution

Any idea what the license is gonna be?

BEA interview (URL posted above) sez Apache license.

Is it related to http://www.thottbot.com/?i=37234 this? :)

Here's a link to an interview with Neelan Choksi, former president of SolarMetric and Sr. Director in BEA's Products department: http://dev2dev.bea.com/pub/a/2006/02/interview-kodo-opensource.html

Hopefully, it answers a bunch of the comments that've come up on this thread.

-Patrick

--
Patrick Linskey
http://bea.com

This is great news - now we have three JPA open source implementations with a variety of licenses to chose from.

Here's a link to an interview with Neelan Choksi, former president of SolarMetric and Sr. Director in BEA's Products department: http://dev2dev.bea.com/pub/a/2006/02/interview-kodo-opensource.htmlHopefully, it answers a bunch of the comments that've come up on this thread.-Patrick-- Patrick Linskeyhttp://bea.com

This is good news, but in my view it is a shame that the JDO implementation is not being open sourced as well. Considering that it can run at the same time in the same application as EJB 3.0 in Kodo, it surely uses most of the same code.

I admit to being more than a little disappointed that the JDO2 libraries and toolsets are included in this annoucenement.

I'm not quite sure I understand why though. Is it to ensure that existing customers of those items don't feel ripped off?

I admit to being more than a little disappointed that the JDO2 libraries and toolsets are included in this annoucenement.I'm not quite sure I understand why though. Is it to ensure that existing customers of those items don't feel ripped off?

I meant to say "aren't included in this announcement."

I admit to being more than a little disappointed that the JDO2 libraries and toolsets are included in this annoucenement.I'm not quite sure I understand why though. Is it to ensure that existing customers of those items don't feel ripped off?

I meant to say "aren't included in this announcement."

Well,
both make sense :))

I admit to being more than a little disappointed that the JDO2 libraries and toolsets are included in this annoucenement.I'm not quite sure I understand why though. Is it to ensure that existing customers of those items don't feel ripped off?

No, JDO will remain closed-source.
But, it is worse to see that their investment will
be blown away in few months.
See also my previous post.

Guido.

How would existing clients feel ripped off? They would still recieve the same or better level of support for their investments from BEA

Nice going! The ride continues...

I have quite a few clients who have picked Hibernate b/c it was free. This is not to say that Hibernate is not good (it is very good). I know of only one client that picked KODO over Hibernate.

Is KODO better?
Does KODO have better tools? (reverse engineering, code generation from mappings)
Is it faster? (I heard that they tuned it for Oracle, DB2 and MySQL)
Is the documentation better?
Is it easier to configure?
Does it have the same amount of feature (or does it have more)?
Does Kodo have a vibrant community?

Have there been any white papers that compare the Hibernate vs. Kodo (ones that answer the above questions and maybe some that I have not thought of)?

Why should someone switch? (or why should they not switch)

I have quite a few clients who have picked Hibernate b/c it was free. This is not to say that Hibernate is not good (it is very good). I know of only one client that picked KODO over Hibernate.Is KODO better?Does KODO have better tools? (reverse engineering, code generation from mappings)Is it faster? (I heard that they tuned it for Oracle, DB2 and MySQL)Is the documentation better?Is it easier to configure?Does it have the same amount of feature (or does it have more)?Does Kodo have a vibrant community?Have there been any white papers that compare the Hibernate vs. Kodo (ones that answer the above questions and maybe some that I have not thought of)?Why should someone switch? (or why should they not switch)

I have had recent experience evaluating Kodo. I can't compare it with Hibernate, but I can certainly report that it is very fast, on Oracle, MySQL and PostgreSQL. The documentation is superb, and there are first-rate tools for two-way mapping. I intent using Kodo because I find that it is very fast and memory-efficient for large transactions with hundreds of thousands of objects. Is Hibernate able to deal with such situations? I don't know, but I have used other ORMs that can't.

I have quite a few clients who have picked Hibernate b/c it was free. This is not to say that Hibernate is not good (it is very good). I know of only one client that picked KODO over Hibernate.Is KODO better?Does KODO have better tools? (reverse engineering, code generation from mappings)Is it faster? (I heard that they tuned it for Oracle, DB2 and MySQL)Is the documentation better?Is it easier to configure?Does it have the same amount of feature (or does it have more)?Does Kodo have a vibrant community?Have there been any white papers that compare the Hibernate vs. Kodo (ones that answer the above questions and maybe some that I have not thought of)?Why should someone switch? (or why should they not switch)

I have had recent experience evaluating Kodo. I can't compare it with Hibernate, but I can certainly report that it is very fast, on Oracle, MySQL and PostgreSQL. The documentation is superb, and there are first-rate tools for two-way mapping. I intent using Kodo because I find that it is very fast and memory-efficient for large transactions with hundreds of thousands of objects. Is Hibernate able to deal with such situations? I don't know, but I have used other ORMs that can't.

Most of the people that I know that have tried both swear by KODO (this is not statistically significant). I know Bruce Tate worked with KODO quite a bit. I'd love to hear him chime in.

Most of the people that I know that have tried both swear by KODO (this is not statistically significant). I know Bruce Tate worked with KODO quite a bit. I'd love to hear him chime in.

I heard Bruce moved to RORO ?

Most of the people that I know that have tried both swear by KODO (this is not statistically significant). I know Bruce Tate worked with KODO quite a bit. I'd love to hear him chime in.

I heard Bruce moved to RORO ?

I think he is a switch hitter. I don't think he is enternally tied to RoR, though that might be his current focus.

I intent using Kodo because I find that it is very fast and memory-efficient for large transactions with hundreds of thousands of objects. Is Hibernate able to deal with such situations? I don't know, but I have used other ORMs that can't.

I just completed a project that used Hibernate to work with tens of thousands of objects. It can handle it, but there are some issues. Regardless of how you set up your caching, it grinds up the JVM. I am currently using iBatis and I would recommend that over Hibernate in situations like that. I cannot speak for how Kodo would perform.

My overall impression with massive volume situations like that would be to keep looking around and prototype the hell out of it.

John Murray
Sobetech

I intent using Kodo because I find that it is very fast and memory-efficient for large transactions with hundreds of thousands of objects. Is Hibernate able to deal with such situations? I don't know, but I have used other ORMs that can't.

I just completed a project that used Hibernate to work with tens of thousands of objects. It can handle it, but there are some issues. Regardless of how you set up your caching, it grinds up the JVM. I am currently using iBatis and I would recommend that over Hibernate in situations like that. I cannot speak for how Kodo would perform.My overall impression with massive volume situations like that would be to keep looking around and prototype the hell out of it.John MurraySobetech

Well, as I said, I have used Kodo for massive volumes (hundreds of thousands of objects in a single transaction) and it works fine, with only the occasional flush of the PersistenceManager required to keep memory use in check. No JVM grinding! But, then isn't this how a good ORM system is supposed to work?

Is KODO better?Does KODO have better tools? (reverse engineering, code generation from mappings)Is it faster? Is the documentation better?Is it easier to configure?Does it have the same amount of feature (or does it have more)?Does Kodo have a vibrant community?Have there been any white papers that compare the Hibernate vs. Kodo (ones that answer the above questions and maybe some that I have not thought of)?Why should someone switch? (or why should they not switch)

This is all IMO, but answering your questions in order:

1) Maybe, maybe not
2) Not really, they both have tools
3) Yes, it's faster than Hibernate
4) Hard to say, I don't find either hard
5) EJB3, I dunno. You can get the same stuff done.
6) The community isn't as big as Hibernate's
7) I haven't seen any, but that's not saying much
8) Usually performance, also licensing (not everyone likes the LGPL)


This is good news, but I do wish they'd included the JDO implementation. That's what most people are referring to when they give Kodo all the kudos.

This is good news, but I do wish they'd included the JDO implementation. That's what most people are referring to when they give Kodo all the kudos.

As I understand it, the Kodo EJB and JDO implementations are built on the same engine, so there is no reason why their JPA should not be as fast as their JDO. However, I also would really have liked the JDO opened-sourced as well. My view is that there is still work to be done to provide a persistence API that combines the strengths of JDO and other approaches. EJB 3.0 persistence is not that API; at least not yet. If both JDO 2.0 and EJB 3.0 were open sourced on Kodo, this may encourage more developers to experiment with both APIs - as they can be freely mixed, even in the same application on Kodo - and so realise how much JDO still has to offer.

Well,
it seems that BEA/Solarmetric decided to kill JDO.
Following Neelan Choksi interview on dev2dev.bea.com
JDO and JDO2 will remain closed-source.
The message is clear: BEA pushes EJB3 technology, despite
the statements in favour of both persistence technologies
made by Solarmetric guys in the recent past.
Noone could have conceived a better strategy to make
EJB3 win.
See also my post on JDOCentral on the same topic.
http://www.jdocentral.com/forums/index.php?showtopic=1591&st=0&#entry7500

Guido

Well,it seems that BEA/Solarmetric decided to kill JDO.Following Neelan Choksi interview on dev2dev.bea.comJDO and JDO2 will remain closed-source.The message is clear: BEA pushes EJB3 technology, despitethe statements in favour of both persistence technologiesmade by Solarmetric guys in the recent past.Noone could have conceived a better strategy to makeEJB3 win.See also my post on JDOCentral on the same topic.http://www.jdocentral.com/forums/index.php?showtopic=1591&st=0&#entry7500Guido

If the core engine is there and implements the meat of the problem, how hard would it be to build a JDO2 wrapper around it? Especially if you have the EJB3 wrapper to look at...

Doesn't seem like a huge issue to me.

Well,it seems that BEA/Solarmetric decided to kill JDO.Following Neelan Choksi interview on dev2dev.bea.comJDO and JDO2 will remain closed-source.The message is clear: BEA pushes EJB3 technology, despitethe statements in favour of both persistence technologiesmade by Solarmetric guys in the recent past.Noone could have conceived a better strategy to makeEJB3 win.See also my post on JDOCentral on the same topic.http://www.jdocentral.com/forums/index.php?showtopic=1591&st=0&#entry7500Guido

JPOX, an open source JDO 2, will shortly release a fully compliant JDO 2 implementation and in few weeks later it's planned to have EJB 3 JPA previews.

With the experience of both APIs, we hope to collect and provide valuable feedback to future releases of these APIs. Maybe these APIs can converge sometime later into a master persistence API?

Yes Erik,
you and Andy are doing a really great job.
But...
What damn market strategy makes BEA move Kodo core
and EJB3 to open-source, leaving JDO and JDO2 closed?
If you want to use an OR mapping solution will you
give a try to EJB3 or JDO (1 or 2) ?
JPOX existence it's OK, but it is not this the problem.
There is an evident differentiation in product promotion
from the creator of one of the best JDO implementations.
And I would say that the same (strategy ?) has happened
to JDO Genie.
First acquired by Versant then moved to open-source and
finally left without support to bring to JDO2 compliance.
Think about this:
Hibernate will be EJB3 compliant and open-source
Open JPA will be EJB3 compliant and open-source
Versant will be EJB3 compliant and open-source

Vendors are pushing EJB3, and they have forgotten
the help from the community to let JSR 243 to be approved.

Guido.

Yes Erik,you and Andy are doing a really great job.But...What damn market strategy makes BEA move Kodo coreand EJB3 to open-source, leaving JDO and JDO2 closed?If you want to use an OR mapping solution will yougive a try to EJB3 or JDO (1 or 2) ?JPOX existence it's OK, but it is not this the problem.There is an evident differentiation in product promotionfrom the creator of one of the best JDO implementations.And I would say that the same (strategy ?) has happenedto JDO Genie.First acquired by Versant then moved to open-source andfinally left without support to bring to JDO2 compliance.Think about this:Hibernate will be EJB3 compliant and open-sourceOpen JPA will be EJB3 compliant and open-sourceVersant will be EJB3 compliant and open-sourceVendors are pushing EJB3, and they have forgottenthe help from the community to let JSR 243 to be approved.Guido.

I didn't know about Versant, but don't forget that Toplink Essentials (or something like that) which is the Reference implementation for JPA is part of Glassfish. It's the same sort of deal as this OpenJPA release, with the core engine and JPA implementation being opensourced while keeping the tools and advanced add-ons as value-add products.

Companies usually do things based on money. If a company releases a significant codebase, such as Kodo or Toplink, to be opensource, then they are doing it because they feel that that can make more money (or save more money) by making it opensource. The idea is to create more use of the product, since it's free and opensource, and make money based on your expertise with the product and the value-added tools and add-ons which were not part of the opensource drop.

BEA obviously feels that a core JPA implementation is not a competitive differentiator at this point (which is pretty apparent from the fact that there will be 4 opensource implementations based on mature codebases). JDO2 is a different market, and one where I've consistently heard that Kodo was the best provider (I've never used JDO, just what I've heard).

Time will tell what comes of the JDO implementation, but as I pointed out, I don't think anyone familiar with JDO would have too much work to do to implement a JDO implementation on the core Kodo engine.

I'm personally more interested in what the availability of the Kodo tools as part of WebLogic Workshop will be... I thought Workshop was becoming free, but with these tools being added, maybe it won't be? Of course, if we could convince someone to make these into IDEA plugins that would be even better :-)

I think you're jumping to conclusions. Big companies often have a challenge figuring out just what to do with the various pieces of technology they acquire. The SolarMetric acquisition was very recent. BEA has moved quickly with Kodo's EJB3 support, and that makes sense; the EJB market is strategic for them. But I suspect the story isn't over, and they're working to decide how best to support JDO as well.

I think you're jumping to conclusions. Big companies often have a challenge figuring out just what to do with the various pieces of technology they acquire. The SolarMetric acquisition was very recent. BEA has moved quickly with Kodo's EJB3 support, and that makes sense; the EJB market is strategic for them. But I suspect the story isn't over, and they're working to decide how best to support JDO as well.

I suspect that JDO support will continue for some time - after all, Solarmetric seem to have build up a sizable business providing a high-quality JDO implementation, and BEA voted in favour of JDO 2.0 last year after having concluded "...that there is a vibrant JDO community which needs this specification, regardless of whether we are successful in achieving an overarching persistence strategy."

I would expect that BEA would want to continue making money from this community. Even if EJB 3.0/JPA is the final word in Java persistence (and I hope it isn't), there are companies who have already invested in JDO and will want continued support for some time.

Hope, hope and hope again.
I fear that the facts say something different.
Let's hope yet.

Guido.

P.S.
If BEA thinks that JDO community is so vibrant, why
do not explain the reason of the choice to leave
JDO closed-source.
Is ther anybody out there ?

Hope, hope and hope again.I fear that the facts say something different.Let's hope yet.Guido.P.S.If BEA thinks that JDO community is so vibrant, whydo not explain the reason of the choice to leaveJDO closed-source.Is ther anybody out there ?

Well, a link was posted earlier on this thread to an article in which a senior director at BEA said:

"Right now, the focus is on supporting the JDO 2 specification and the EJB 3 Persistence specification and offering customers interoperability between the two specs. Both of these specifications are very close to being submitted to the JCP for final approval, and we would very much like to be right on the heels of the approvals with GA versions of Kodo and Open JPA."

They are supporting the JDO 2.0 specification. That dealt with my concerns!

Regarding the open sourcing....I don't see what having open or closed source has to do with the matter of supporting or not supporting an API. Kodo (and others) have had success for some time with closed source products. What matters to me personally is quality and support - having the source would be nice, but not one of my primary considerations. I would imagine that many developers share this view.

If BEA thinks that JDO community is so vibrant, whydo not explain the reason of the choice to leaveJDO closed-source.

My guess is that Solarmetric/BEA realizes JDO2 is superior in the SQL optimization area (fetch groups, hints, etc.) vs. EJB3, so they're giving out JPA for people to play with and then when they come back with performance issues, they'll sell them upgrades to KodoJDO with scripts to sed s/Entity/Persistence/g. ;)

Bea open sourced a version of its relational database mapping tool "Kodo" under an Apache license, while continues to offer BEA Kodo under a closed source license.
So what was opensourced ?

--lokesh
http://lokeshpant.blogspot.com

Bea open sourced a version of its relational database mapping tool "Kodo" under an Apache license, while continues to offer BEA Kodo under a closed source license. So what was opensourced ?

The title of this article is somewhat misleading. There are (will be) two APIs which allow use of the Kodo engine: EJB 3.0 (JPA) and JDO 2.0. Unless I am mistaken, the engine + the JPA API implementation are being open sourced.