Petition to the Java Community Process Executive Committee

In regards to: JSR 243 Public Review Ballot, from Jan 18, 2005

Java Data Objects 2.0: Adopt the extension to the existing JDO 1.0 standard

Dear JCP Executive Committee,

We have been tracking JDO2.0 all along and anticipating the powerful features of JDO2.0 which can greatly further improve our development. And we feel very upset  to see the result of the recent Public Review Ballot.

I am now writing to urge the JCP Executive Committee (JCP EC) to adopt the Java Data Objects 2.0 draft in the upcoming public review ballot. I am very concerned about the outcome of the initial rejection of the JDO 2.0 draft. If JDO 2.0, an extension of the existing JDO 1.0 standard, is not approved, it will cause significant damage to developers and vendors that rely on JDO, it will create irreparable damage to the reputation of the Java Community Process, and it will hurt the Java developer community at large. Not accepting JDO 2.0 and referring developers to a future EJB standard, which most likely will not be available for some time, leaves a significant void in the market for a robust Java persistence standard, causing it to be filled by proprietary products and solutions.

Here are some of the facts that you should consider for the upcoming vote:

JDO 1.0 is a very successful JCP standard and it has received broad adoption in the industry. JDO 2.0 builds upon JDO 1.0 and addresses additional market requirements. How can the JCP executive committee (JCP EC) abandon such efforts without offering a solution available now to meet the current needs of Java developers?

The JCP passed the original JSR 243 and gave the expert group the charter to continue working on the JDO standard for JDO 2.0. The Expert Group has accomplished the objectives of JSR 243. There is actually no debate, whatsoever, about the technical merits of the new draft. How can the JCP EC simply reject the work of the expert group, who received the JCP’s blessing in the first place?

Vendors AND developers have already adopted many of the useful JDO 2.0 extensions. The standard is very much alive and many companies have deployed systems using JDO. It has already proven to be the best, most widely used, persistence API ever developed. JDO 2.0 addresses areas of standardization that had been deferred until after the JDO 1.0 release. Valuable work from experts, developers and vendors are in jeopardy, resulting in the loss of millions of dollars for many companies.

JDO 2.0 is NOT positioned against any EJB specification. From the beginning, JDO has addressed needs that have not been met by other Java specifications. With the announcement in September 2004 to "join forces" with the JSR 220, there was a clear path as to how JSR 220 will benefit from the excellent work already performed and adopted in the market. Why abandon this path and create confrontation between the expert groups?

One of the major features of JDO 2.0 is standardization of the XML metadata syntax for defining the mapping between Java objects and relational tables. In current JDO 1.0 implementations, this syntax is vendor-specific and proprietary. Standardizing this mapping metadata in JDO 2.0 will increase the level of standardization and portability of applications, reducing the developer-visible differences among implementations. It will also reduce the migration efforts for those in the industry that want to migrate from JDO 2.0 to the future EJB specification. If the JCP EC is concerned about reducing the level of developer confusion and the number of alternative APIs that are available, they should welcome these enhancements in JDO 2.0. The current JDO community has been requesting this standardization and other features provided in the JDO 2.0 API. Who is better qualified to judge the value of the JDO 2.0 API than existing JDO 1.0 users?

If the final vote of the EC Committee is against the JDO 2.0 draft, it will most definitely cause JDO to become a standard that the JDO vendors will continue to develop outside of the JCP and it will flourish. An important capability such as Java Persistence should be part of the JCP. JDO 1.0 has been available as that JCP standard for 3 years, and now JDO 2.0 is available. Implementations of the future EJB persistence API are not likely to be released for another 1.5 – 2 years. Current JDO 1.0 users and developers that want an object persistence solution now cannot wait for this future API. JDO vendors and their users will continue to use JDO, causing them to abandon the JCP as their platform.

The JDO Expert Group is committed to align with the JSR 220 Expert Group. As stated in an open letter to the Java developer community, several JDO experts have already joined the JSR 220 expert group to align with the future results coming from JSR 220 regarding O/R mapping (EJB QL 3, O/R mapping annotations, some APIs...). JDO 2.0 is done now and can serve needs in the developer community today. Once the JSR 220 specification has been completed, at that point in time the JDO expert group can work to provide alignment, beyond the level alignment they can provide through their participation in the JSR 220 expert group. Trying to force the demise of JDO by voting against JDO 2.0 will not motivate the JDO community to promote cooperation and alignment of the APIs, it will simply further divide the market.

In summary, it is in the best interest of the JCP, the Java developers and the JDO vendors to adopt JDO 2.0. I am urging you once again to consider the many negative implications of rejecting the JDO 2.0 draft. The JCP Executive Committee is an elected board that should represent the Java developer community as a whole. It should not act as if its sole role is to push the agenda of a single API still under development (JSR 220). As a concerned Java developer, I believe that you need to listen to what the market really needs and wants.

I would appreciate a reply to my concerns.

Sincerely,

Bin Sun