We have, since 2006, been reliant on the Apache JDO project to push forward the JDO standard. Politics have finally become too much for this arrangement, with Oracle involving lawyers to prohibit progress, and the Apache organisation not being as rapid as it should be at getting releases out of the door. I have now forked their API (now present in DN GitHub). The aim is for this repository to be used to develop JDO 4.0 (and maybe later dependent on people’s involvement), initially to get a TypeSafe query mechanism into the JDO API (originally contributed back in April 2010!!), and bring the API up to date wrt generics in queries themselves. There are also many other features that were requested in Apache JDO JIRA over the last few years that have been simply left, but are needed.
If you, or your company uses JDO this is your chance to get involved and push it forward to cater for these required features. Do you really want to have to cast the return from your Query to be a List etc. You could offer your real-world experience with the JDO API and what you think could be done to make it easier to use.
Should the Apache JDO project “wake up” at some point in the future we could easily enough merge our changes back into their API and discontinue this fork.
DataNucleus 
Is there any reason to support JDO if only implementation drop support for it?
I saw about youd previous post about drop JDO enchancement contract. No more PersistenceCapable, JDO API as dep and stong documented contract on enchancement (what JPA not have).
LikeLike
As per the previous topic, JDO support remains in DataNucleus. This is to provide an improved JDO API, with more features. I would have thought that this is a good thing.
But then judging by the usual lack of people volunteering to help out here who knows how far this will get. People say they want such things, but then there's never any investment in it … Perhaps they just want it if its free
LikeLike
Ok, what kind of help we can provide?
On some of our projects we have 'infrastructure' dev hours, we cat spend it to Datanucleus as already do previously. More over we have 3 not proposed patches because switch to git. I try to migrate it to git and send to you.
LikeLike
What can you do ? JDO 4.0 is the perfect chance for people using JDO in their applications to define where they think things can be improved with the JDO spec, and suggest ideas. Or where you have to do something in your application that JDO doesn't cater for, so we see if we can provide it as a general feature.
If you have outstanding patches then update them to match GitHub codebase (much is changed), and contribute them (raise an issue for each one, and attach the patch or Git Pull Request to the issue). Thx
LikeLike
My roadmap for JDO:
1. Support for generics.
2. TypeSafe queries
3. Binary temporal operators in queries (datetime + interval, datetime + datetime , etc)
4. Ability to customize persistent object creation. For injection or some other custom initialization.
5. TypeConverter's with support for multiple columns in datastore (if it applicable for JDO itself).
6. Ability to redefine class on JDOImplHelper .
About patches – we are working on migration.
LikeLike
JDO should support standard a way deal with DEPRECATED fields / TYPE changes. When there are changes in the database tables (ex: a field TYPE change), the only option until now is to keep the old column and define a new one…
1) A field USAGE change – I suggest a new persistence-modifier value (ex: “deprecated”). This would map the field as “read-only” and would not create it in the database table if it was not present. This should be conjugated with another standardized way to DROP columns (after they have been defined as “deprecated” and converted by the app).
2) A field TYPE change – If a field type change is detected, it should be made automatically, if possible, or at least using method 1 (deprecate, convert, drop)
LikeLike
So in conclusion to this item, nobody is willing to put their time into developing a new version of JDO. “Wish lists” are all well and good but we already have those.
LikeLike