As the rejection of the JSR 243 shows, one of the most promising persistence strategies for Java, JDO, is doomed to fail. One could say that on a later time errors could be corrected. But nowadays we cannot affort waiting too long with most important aspects of an architecture.
I have been concerned about Java persistence in general since I began coping with persistency in Java. For me, there is no really satisfying mechanism available fitting to the (sub-)enterprise level. The current release of SAP NetWeaver for Java shows that JDO is still in its early days, at least the support for it in enterprise architectures. Look at SAP legacy architecture (ABAP): There you have it all at no cost, no need to do these ugly things necessary with JDO, EJB persistence, Hibernate and all the other stuff. I don't have anything against Hibernate, particularly. it's a good piece of open-source software. But in my eyes it's not enough compared to what can be possible.
Look at the approach Yi Zhou developed. Admittedly, I have not read it all, it may be ingenious, I don't know. But if, then at what cost (complexity)?
BTW: Tell me which *integrated* Java architecture to use for commercial projects containing persistence, business logic, view mapping, GUI etc. with a different name than J2EE? I personally don't like J2EE in any way. It's much too complicated, slow, non-agile, somewhat cryptic, redundant in the way you need to code, complicated (Design Patterns... oh my god, most people are happy when knowing about AbstractFactory or Observer...).
What I was wondered all the time how a single person such as Doug Lea made it to the elitary club of JSR reviewers. Good job, Doug. Although it is astonishing that he did not make a comment on his vote and is in sole company with Apple...