What role is the JDO in ObjectDB?

Mike Keith believe the JDO is out of date.

Then what role of JDO in ObjectDB?

Will our codes with JDO be out of date?

Due in part to some of the failures of the EJB persistence model, and some frustration at not having a satisfactory standardized persistence API, another persistence specification was attempted. Java Data Objects (JDO) was inspired and supported primarily by the object-oriented database (OODB) vendors and never really got adopted by the mainstream programming community. It required vendors to enhance the bytecode of domain objects to produce class files that were binary-compatible across all vendors, and every compliant vendor’s products had to be capable of producing and consuming them. JDO also had a query language that was decidedly object-oriented in nature, which did not sit well with relational database users, who were in an overwhelming majority. JDO reached the status of being an extension of the JDK, but never became an integrated part of the enterprise Java platform. It had many good features and was adopted by a small community of devoted users who stuck by it and tried desperately to promote it. Unfortunately, the major commercial vendors did not share the same view of how a persistence framework should be implemented. Few supported the specification, so JDO was talked about, but rarely used. Some might argue that it was ahead of its time and that its reliance on bytecode enhancement caused it to be unfairly stigmatized. This was probably true, and if it had been introduced three years later, it might have been better accepted by a developer community that now thinks nothing of using frameworks that make extensive use of bytecode enhancement. Once the EJB 3.0 persistence movement was in motion, however, and the major vendors all signed up to be a part of the new enterprise persistence standard, the writing was on the wall for JDO. People soon complained to Sun that they now had two persistence specifications: one that was part of its enterprise platform and also worked in Java SE, and one that was being standardized only for Java SE. Shortly thereafter, Sun announced that JDO would be reduced to specification maintenance mode and that JPA would draw from both JDO and the persistence vendors and become the single supported standard going forward.

There is no plan to remove JDO support from ObjectDB. On the contrary, new JDO features are expected to be added to  future versions of ObjectDB. Support of JDO by ObjectDB is currently the most extended and up to date among all the JDO implementations except the JDO reference implementation itself (DataNucleus).

However, it is true that JPA is more popular than JDO and it is has some important advantages such as better integration in Java EE containers (application servers). Therefore, for new applications JPA may be more attractive. This is the main reason why the documentation and tutorials of ObjectDB 2.x focuses on JPA.

JPA and JDO share many common features. Using ObjectDB makes it easier to convert applications between these two standards in the future, since the ObjectDB file format is the same - so there is no need to convert data.

The FAQ contains more details about JDO and JPA in ObjectDB.

Thanks for your reply.

I found a flaw in JPA that the @Index can not be used. These is an example in ObjectDB which used @Index, I traced it to the JDO lib. So if I want to make a index without SQL on database, then @Index is a mandatory function.

Any suggestion on @Index?

You are right - setting indexes is currently missing in JPA.

It be added in JPA 2.1. Meanwhile - use JDO annotations for indexes. 

See the Index Definition page in ObjectDB manual for more details.

Then, what is the difference between JDO's Index and ObjectDB's Index?

Or, ObjectDB package the former? If so, the purpose of the JDO may be only for Index?

Yes, ObjectDB uses JDO annotations for indexes. So if your application is based on JPA - the only place in your code that you are actually using JDO is in index definition.

But it is easy to keep your code portable to other JPA providers by adding their @Index annotations, e.g.

    @javax.jdo.annotations.Index                  // ObjectDB, DataNucleus
    @org.hibernate.annotations.Index(name="name") // Hibernate
    @org.eclipse.persistence.annotations.Index    // EclipseLink
    @org.apache.openjpa.persistence.jdbc.Index    // OpenJPA
    private String name;

Notice, that Hibernate, EclipseLink and OpenJPA provide their own @Index annotations. DataNucleus and ObjectDB use @Index annotation from JDO. All annotations will have to be replaced in future versions with a portable JPA annotation.

Thank for your answer.

TIA