The Apache DB group voted on a new JDO proposal. The new proposal was brought to Apache by various leaders in open source, and JDO:

• Abe White, SolarMetric, JDO expert group member
• Brian McCallister, OJB committer
• Craig Russell, Sun, JDO Specification Lead
• Dain Sundstrom, GlueCode, Geronimo committer
• Erik Bengtson, JPOX committer
• Geir Magnusson, GlueCode, Geronimo committer
• Michael Bouschen, JDO expert group member
• Michelle Caisse, Sun, JDO TCK developer
• Patrick Linskey, SolarMetric, JDO expert group member
• Victor Kirkebo, Sun, JDO TCK developer

There are six initial subprojects envisioned:

• JDO 1.0 API
• JDO 1.0 Reference Implementation
• JDO 1.0 Technology Compatibility Kit
• JDO 2.0 API
• JDO 2.0 Technology Compatibility Kit
• JDO 2.0 Geronimo integration

Read the full proposal

NOTE: Someone already asked "Doesn't OJB support JDO?" to which Brian McCallister replied:

OJB supports a JDO interface via a plugin to the JDO 1.0.X reference implementation (which is SCSL, non-commercial variant) so is basically useless right now. This same RI is part of the initial codebase for this project, so the OJB JDO 1.0.X interface can actually become useful =)

Dion,

The link points to the mail archive and not to the proposal....

Dion,The link points to the mail archive and not to the proposal....

Looks like the actual link should be the top message in the thread the current link goes to:
http://www.mail-archive.com/general at incubator dot apache dot org/msg04058.html

Dion,The link points to the mail archive and not to the proposal....

Looks like the actual link should be the top message in the thread the current link goes to:http://www.mail-archive.com/general at incubator dot apache dot org/msg04058.html

Interesting!

"The plan is to migrate the existing JDO 1.0 code base, including the API, RI, and TCK to Apache. Subsequently, development on JDO 2.0 will commence, using the JDO 1.0 code as a starting point. The API and TCK will be implemented entirely as Apache sub-projects. The licenses will be changed to be Apache licenses.

The JDO 2.0 Reference Implementation will be developed outside Apache (in SourceForge under the JPOX project). The license will be Apache 2.0 from the beginning."

... by itself would represent a significant step forward.

Thanks Gordon.

I changed the link to the TOP message which has the proposal in it.

Dion

The Apache DB group voted on a new JDO proposal.

The purpose of the project is not clear (maybe because the link to the proposal was wrong, so I did not read the required litterature).

I doubt the idea is to start a clean-room implementation of JDO from scratch. There are already open-source implementations of JDO available: JPox, and also Speedo for instance (http://speedo.objectweb.org) - that experts like Craig could not be unaware of.

Are we here speaking of Sun open-sourcing... something, like actually contributing existing code?

Big kudos to Craig and all the other folks who made this happen.

If Tomcat is any indicator, Apache is capable of producing top-notch implementations that go go way beyond what one would expect from a "reference".

This is big.

-geoff

Does anyone know what the implication of JDO's move to ASF will mean for the proposed unification of EJB 3.0 and JDO 2.0 under a common persistence API? I get lost sometimes in all these machinations. Not suggesting for a minute that the move is unwise.

Outsourcing development is frequently the first step that a company takes to distance itself from a technology... Perhaps this is not the case (it certainly wasn't when Sun contributed Tomcat to Apache).

Given Apache's track record, I think that the likelihood that their JDO implementation will share the EJB 3.0 persistence API is increased.

Given Apache's track record, I think that the likelihood that their JDO implementation will share the EJB 3.0 persistence API is increased.

As it states in the article, Apache are developing the JDO.jar and the JDO TCK for JDO 2.0. They aren't developing the reference implementation for JDO 2.0. That is being done outside of Apache by the JPOX project.

Given Apache's track record, I think that the likelihood that their JDO implementation will share the EJB 3.0 persistence API is increased.

As it states in the article, Apache are developing the JDO.jar and the JDO TCK for JDO 2.0. They aren't developing the reference implementation for JDO 2.0. That is being done outside of Apache by the JPOX project.

Yes, but the proposal also states:

Subsequently, we will attempt to integrate with the persistence engine currently under development for Geronimo EJB. This engine, known as Tranql, will be investigated as the common persistence engine for both EJB and JDO in the J2EE 1.5 timeframe. The binding to Tranql will be done as a separate sub-project in the Apache JDO project.

Very welcome development. Having just become the official RI for JDO 2.0, JPOX now can give EJB 3.0 Java persistence vendors a run for their money.

As a side question, is ASF Geronimo involved in JSR-220 EG (EJB 3.0) as well?

JDO is dead,there is no future of it at all and i think that no software house is planning new project based on it,sun focus their effort on EJB3 and gave the jdo to apache for maintenance and that makes me nervous as i think apache is always on the front, developing for the next generation technolog,and defining new concept ,not mentaining a dead product for another company , i think that the apache valenteers donot wast their time for a project will b completely dead in 18 month

JDO is dead

This coming from someone who's probably never used JDO, and who also owns stock in BEA. ;)

Thanks for the oh-so insightful commentary.

God bless,
-Toby Reyelts

Hi Joe

JDO is moving forward. The main JDO vendors are committed to supporting both JDO 2 and the new persistence API in their products. Right now JDO is exactly what companies moving to POJO persistence should be using. It is the only POJO persistence standard and is well supported by vendors with products that have been in production for several years. The new standard is a long way off.

Versant Open Access will provide seemless integration for applications using JDO and the new persistence API. You will be able to use both APIs in the same application with the same model if you need to.

Cheers
David
Versant Open Access for Java and .NET

hi all
we must agree that all the major vendors(oracle,ibm,bea) dislike jdo (they voted againest jdo2 in jcp) and also sun movement is to promote EJB3 and its unified model so all the big houses moving the other direction, and since Gavin King (the lead developer of hibernate)is the spec lead of EJB3 then we have to know that hibernate 3 is EJB3 early access so even i not prefer the hibernate license i must use it as it is the window to the future
think about it twice and decide for yourself
and by the way i developed with jdo and know that is really good especially for it's good defined object lifecycle but it's incomplete query language make me really sick

and since Gavin King (the lead developer of hibernate)is the spec lead of EJB3

With all due respect to Gavin, but last time I checked, the spec lead for JSR-220 (EJB 3) still was Linda DeMichiel, who works for Sun Microsystems.

but it's incomplete query language make me really sick

On a more serious note, what do you feel is missing from JDOQL?

Hallo everyone (my first post on this site ;-)

I have worked on serveral large scale applications using JDO as a consultant for Versant.

One particular customer used traditional JDBC, home-grown O/R mapping solutions and hibernate before - and failed.

When we showed them JDO the core developers were immediately impressed, but there were many doubters. Now the first project is finished and the doubters are silent. The project was completed in due time and in budget and the result is much faster than they hoped for.

One key ingredient in this success was to keep querying to a minimum and let JDO do the navigation. Even complex requirements can be elegantly expressed with what is available in JDOQL already. If you need to use the complete SQL syntax all the time you are probably still thinking too much from the database side and not from the client side.

There will always be the odd exception, and many commercial JDO implementations will allow you to include pure SQL statements as well as JDOQL statements. In my applications I have not needed this.

From my experience, JDO is here to stay. There are hundreds of large customers using JDO now, and the majority is very happy and will not turn back. Not all of them are using EJB containers, for them EJB3 is not an option, let alone the fact that there is nothing available right now. 18 months is a long time in this industry and you cannot hold development for such a long time waiting for something noone at the moment really knows what it will deliver.

Sven Erik Knop
Principal Consultant
Versant UK

One particular customer used traditional JDBC, home-grown O/R mapping solutions and hibernate before - and failed.

excuse me for this: that's stupid!!!
if your client failed with hibernate, it's just because your client didn't know how to use it.

Let's take a real example.
I'm working in a big (60 000 employees) commercial society in critical apps.
In a critical use case:
before optimisation: 762 generated queries + 10,5 seconds response time.
after optimisation: 2 generated queries + 1,5 second response time for a big object network and huge amount of objects.

It's all about being an expert in what you are using and thanks to the hibernate team to support for free the beginner i was two years ago.... now i'm helping the other on the hibernate forum since i'm an expert in Hibernate.

Is Versant doing the same? humm humm !

Anthony Patricio
working (free) with the hibernate team
see you soon on the hibernate forum ;)

I find it hard to believe that Apache would take on a product if all they saw in it for themselves was bug fixes.

The combination of JDO and Tomcat is smokin', and serves the needs of a large percentage of web-applications. Give me detachment and then 'rich' clients will be a reality too!

Now if JSR 243 would just hurry up and get finalized the momentum would build and then we could forget the overblown EJB3 containers and the unified (vaporware) persistence API.

JDO is dead,there is no future of it at all and i

Hi Joe,

I think that saying JDO is dead is a bit harsh. :o)

Personally I think that relational db being used made up a really big percentage of applications. With relational db and an OO language like java there is definitely, IMO, a mismatch, the richer the domain model, the greater the mismatch, i guess. This, i think, is where ORM like JDO or Hibernate comes into play.

Actually, I can't imagine not using an ORM sollutions like hibernate (especially when there is a rich domain model). EJB3 looks promissing but Hibernate is available now and most projects need a solution now. I don't think JDO is going to die any soon, just as relational db is not going to get replaced by object-oriented db soon either.

Just my opinion, that's all.

:o)

regards
tmjee

>>> especially when there is a rich domain modelis it a good idea to hit your relational DB by the rich OO domain model for big scalable applications ???

I think it is better to have a domain model that closely represents the business domain (if rich then so be it), that one could manipulate in java, let ORM like hibernate do the translation to relational sense. It is good to be able to do inheritance, have a component (hibernate "component" or "composite element") or something that like without having to worry too much about how to manipulate them in the relational sense in the domain model. If say (in hibernate) inheritance maintained one table is not desirable, switching to inheritance per table could be done pretty easily by just changing to mapping configuration, the application sees no different cause the mismatch is handled by hibernate. This is a kind of rich domain model to me. :o)

If performance is an issue, we could twieak the ORM to optimise the sql generated. Hibernate provides lots of way to do that, eg. lazy loading, caching etc (which depends on what is best to used).

We might want to have an interceptor that trace transactions, so we have a rough idea which trasaction is taking the longest time and need optimization.

Just my thoughts. :o)

regards
tmjee

JDO is dead,there is no future ...

Since 3 years few individuals continuously claim that JDO is dead and so on. The fact is JDO is very active, with at least 30 implementations (both commercial and open source) and many deployed projects. The expert group is growing and listens to the users community: the upcoming new version 2.0 will include a more complete QL, O/R mapping standardization, byte-code enhancement made optional...

In october, Sun tried to calm down the "war" between EJB and JDO, but it seems there is still a little bit more communication effort needed in this place.

JDO uniquely addresses several requirements of the market, as heterogeneous data access for instance. JDO won't disappear.

Best regards, Eric.

I work in a j2ee application generator that use
EJB CMP2 for persistente.

For years I'm looking to JDO, wait for a mature
open source implementation, to migrate to JDO.

But now with EJB3/JDO fussion, the more prudent
idea maybe use hibernate.

Hibernate downloads/month is about 30000
jpox download/month is aobut 3000 (10%)

If you are interesed in a mature open source OR implementation
now (not in 2006)...

Is there something out of hibernate?

JDO is dead,there is no future of it at all and i think that no software house is planning new project based on it

Disclosure: I work for a Xcalia, a leading, commercial JDO vendor.

I wish people would stop saying things like this and give JDO a try themselves. Then, they would see what a joy the API is to work with.

I believe that JDO has a bright future, especially with the upcoming additions in JDO 2.0. Judge the technology for yourself based on its design and ease-of-use, not what someone else says about it.

Version 3.1 of LiDO XD, our JDO implementation, coming in January, will allow you to develop & test against all data sources, relational or not (including flat files, XML files, mainframe databases, and Versant's object database), and it will even allow you to go to production against any open-source RDBMS with a limitation of two concurrent sessions, completely free of charge with no time limitation. It will also offer several previews of the JDO 2.0 feature set.

LiDO XD 3.1 will allow everyone to try out JDO to their heart's content so that they can see the ease of development that it brings to the table. Shoot, you can download LiDO XD 3.0 right now and get a trial license that will tide you over until 3.1 is out, so give it a shot. What do you have to lose? Give me a call or drop me a note if you have any questions.

--matthew

Matthew T. Adams
Corporate Technical Advisor & Senior Consultant
Mobile: +1 253 732 1051
Phone: +1 206 331 3833
Fax: +1 360 937 9616
matthew.adams@xcalia.com

Obviously, JDO is not dead, but there have been many attempts on its life. Usually, when people attempt to kill a technology their motivation is fear. They find the technology threatening. Moving JDO into open source is one of the best ways to remove it from the machinations of entrenched interests. The supporters of EJB 3 will have to come up with a better persistence framework than they have in the past to compete with JDO. That is good news for application developers.

At the same time, current implementations of JDO correctly see that their support for JDO 1.0 and JDO 2.0 is a feature of their software. They will support additional features in response to market demands. One additional feature may be support for EJB 3.0's persistence API. For everyone who decides to use that API, the support of vendors who currently have persistence frameworks will be good news.

Hibernate is a fine open source project, but there is no way to ignore the fact that applications that use it are currently locked into one implementation. Likewise, comparing download statistics for Hibernate with download statistics for JPOX should not ignore the fact that there are several open source JDO implementations and many more commercial implementations.

So, no doubt the war of words will go on, but developers should examine the issues when making their choice. JDO offers a JCP standard, is agnostic about database architecture, has multiple implementations, and is readily available in commercial as well as open source implementations. Whatever you might conclude, JDO should certainly be considered a live contender that can pack a real punch when compared to the alternatives.

David Ezzio

Thank you David Ezzio! I agree totally!

of course, the real problem with hibernate is that the proprietary persistence APIs and hibernate-specific mapping/configuration files provide vendor lock-in for the benefit of the JBoss group and to the detriment of customers.

If you use Apache JDO, JPOX, Versant JDO, Kodo, etc, then you get an app that's portable between competing vendors, and your development team have skills that are transferable from one product to the next.

Applications developed with JDO now will be supported by backward compatible JDO 2 + EJB 3 products going forward - providing a smooth migration path to future product versions. Applications built using the hibernate specific APIs, config-files and HQL are stuck with a single vendor, or face non-trivial migration efforts to EJB 3 in 18 months.

...I thought one of the key reasons that we all love Java so much is because of its portability? ;-) ...just my 2 cents.

Dave.

of course, the real problem with hibernate is that the proprietary persistence APIs and hibernate-specific mapping/configuration files provide vendor lock-in for the benefit of the JBoss group and to the detriment of customers.

ROTFL:
 - Hibernate is hum LGPL (waouh, so locked-in!)
 - Year JBoss is evil, hiding the code, adding back-doors to slave their customers. Hum, Oh I forgot its Open Source, damn it!
 - Everything claiming their dislike against JDO is pure evil and want to lock you in, look at their strategies : they have ODMG3 support and do a major contribution to EJB3, I've got my clue here!

and your development team have skills that are transferable from one product to the next

Well except for the really real-life interesting part, tuning and fine-tuning.

Applications developed with JDO now will be supported by backward compatible JDO 2 + EJB 3 products going forward - providing a smooth migration path to future product versions. Applications built using the hibernate specific APIs, config-files and HQL are stuck with a single vendor, or face non-trivial migration efforts to EJB 3 in 18 months...

18 months, hum except that Hibernate is very close to show you an implementation of the EJB3 early draft. Did you read the EJB3 draft and looked at what's inside? Did you looked at and see any hard migration path from Hibernate to EJB3? Of course you don't, because if you had looked at it for real, you wouldn't have post such an assertion.

ROTFL:
 - Hibernate is hum LGPL (waouh, so locked-in!)
 - Year JBoss is evil, hiding the code, adding back-doors to slave their customers. Hum, Oh I forgot its Open Source, damn it!

There seems to be frequent confusion between 'proprietary' and 'open source'.

Just because a product is open source, does not mean it is not proprietary. Just because a product is open source does not mean that a vendor can't add extensions to encourage users to stay with that product.

Why does this matter?

Well, no matter how widely used a product, or how well-supported the vendor, there is always a chance that the vendor may abandon the product, or move it towards a new direction (before anyone flames me at this point, please see my comments about Hibernate below). Some developers (like me) like to stick with a principle of caution: use products that conform to standards so that you can switch vendors rapidly in case of problems. A product being open source or not has no relevance to this principle - I have no desire (or time) for hacking source code in the case of a vendor getting into trouble.

I'm certainly NOT saying that this is likely with Hibernate! Hibernate is a superb product, and it would not have been so widely used if this were not the case. I am not implying in any way that the developers of Hibernate are likely to abandon it! However, personally, I feel safer with standards, as do a significant number of developers. I have alternate standards-compliant suppliers for my J2EE engine, my Java VM and SDK, my operating system and my database. I also want alternate standards-compliant suppliers for my POJO persistence mechanism. Perhaps, when EJB3 POJO comes out, Hibernate will meet my criteria of a competing supplier of that new standard API, and I look forward to that situation.

+1

why on earth, there are always someone launching a "myProduct versus Hibernate (or other)".
What you are saying is VERY dangerous and you're lying guy!
Just remind how persistance was 3 years ago, people coding many hours on ejb specifics and nobody's really able to use a rich domain model + bad performance.
JDO tried to make it easier.... but failed (at least first), no matter they tried.
Gavin King (Christian, Emmanuel, Steve, David, Max, Michael,...) did it!
Just download the sources and tell everybody here what is proprietary.
Next point, many hibernate users are used to work with hsqld or mySql in development and it's Oracle in production (without changing the code or mapping files). Isn't it a clue that hibernate is not locking your app to the initial database product?
Then, i've migrated from hibernate 1.2 to 2.0 then 2.1.7 without any problem and i'm looking to switch to Hibernate 3... i think we'll do it in 2 weeks for many of our apps (just have to rewrite 10% of our DAO layer), so if you guy need 18 months, let me say you should find another job because you're missing something (joking ;)).
Last i must say that i'm not working for JBoss. I knew Hibernate before JBoss and i know it after, nothing has changed except that companys can get great training and support to avoid this:(https://www.theserverside.com/news/thread.tss?thread_id=30443#148973).

Man, you are a very dangerous guy and are not helping nobody since you don't know what you're talking about.

I won't blame JDO cause i don't know about last features so if you have never used hibernate, please shut up.