It pains me to say it, but it’s true. I was as passionate as anyone that the JDO 2.0 spec, JSR 243, should be approved (and it was). A friend just asked me what persistence approach I’d recommend for new development – based on comments from the approval of the JDO spec, I just couldn’t recommend it. Unless something big changes in the Executive Committee, JDO will get one more release to define the migration path to EJB3, and then they pull the plug. Will your vendor still support you? Sure. Will the idea of JDO probably live on in some form? Absolutely.
It all depends on your goals, but if your goal is portability via standards compliance, almost any approach you’d choose right now for POJO Java persistence sets you up for a guaranteed migration to something else in the near future. JDO is becoming EJB3-related persistence, as is Hibernate and probably other open source ORM solutions, and the TopLink/Oracles of the world don’t really want your app to be portable in the first place. I recommended Hibernate – because it’s mature now, and is HEAVILY influencing the future of EJB3, far more than JDO is. As such, though it’s not standard now, the end EJB3 result is likely to be an easier migration from Hibernate than from JDO. Of course if you’re already using JDO, the fact that they’re offering a migration path makes it clear that you should stick with JDO until you choose to take that step to EJB3. I’m not saying to dump it for existing projects.
Is it an easy decision? By no means. But recognize that JDO’s funeral has already been planned. Barring a JCP revolution, coding new applications in JDO is building your app on a dead man walking.
Rob's Blog - Technology, Atlanta, Startups and Stuff 
I don’t know too much about the JDO saga, having many years ago started to follow the Hiberante path. I do however well more Hiberante developers to the fold. š
Any, as Howard Lewis Ship says, “Results, not Standards”.
Just use EJB 2.1 CMP Entity Beans. They work, and there is a standardized specification, with multiple competing implementations that span every range of price, maturity and stability. And presumably there will be a clearly defined migration path from EJB 2.1 to EJB 3.0 when it comes out.
Notice I said POJO. EJB 2.1 is an option if and only if you’re running in an app server with an EJB container. I was asked about containerless persistence, so EJB is out.
JDO is far from dead, regardless of what JBoss and Oracle want. It will continue to be developed under Apache, and Sun has stated that there will be future revisions of the specification as needed. Given these facts, and the fact that JDO 2 already has features that won’t be in EJB 3 until one or more spec versions down the road, I think JDO has a long and healthy future.
In addition, you might want to rethink your opinion on ease of migration. I know at least two major JDO vendors — SolarMetric and Versant — have both stated that they will support concurrent access to both the JDO and EJB 3 APIs in the same application, even on the same object instances! That is as perfect a migration path as you can get. If I were recommending something to clients, I would put JDO at the front of my list.