近日，针对JDO2.0的投票结果，Java社区议论纷纷，很多关注JDO的用户（包括笔者在内）对投票结果感到失望，并纷纷致函要求重新进行投票。www.JDOCentral.com 的站长Dirk Bartels草拟了一份请愿书，希望更多的JDO用户能够根据自己的实际情况稍加修改，并向JCP（Java标准制定组织）的执行委员会发函，请求慎重考虑，并组织重新投票。
在这里，我也以一名JDO用户的身份希望使用过JDO并希望JDO2.0能够早日投入使用的用户都来参与递交请愿书。具体操作就是在下面这个网址提交在线请愿书：
http://www.jdocentral.com/JDO_SignOurPetition_Form.html
如果对表单中的内容根据自己的情况写得更具体一些，效果会更好。下面我也将我修改过的内容公布出来，供大家参考和分享。
拯救JDO，人人有责！
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’re Pacific Online Co. Ltd., the largest Information-Technology consultancy portal in China, and we have put lots of investment on JDO in the last two years. We have four large websites as listed below:
http://www.pconline.com.cn , one of the top 100 websites (http://www.alexa.com/data/details/main?q=&url=http://www.pconline.com.cn)
http://www.pcauto.com.cn , one of the top 500 websites(http://www.alexa.com/data/details/main?q=&url=http://www.pcauto.com.cn)
On these websites, we have migrated most of the related projects to JDO, developed by our own team of which I am currently in charge. These projects have various characteristics respectively, and all confirmed that JDO is a mature and powerful technology with attractive features and full scalability.
For example, http://price.pcauto.com.cn is one of the core projects on http://www.pcauto.com.cn, which provides up-to-date and complete information on automobile products, prices and dealers, etc. It proved that JDO can be used on not only simple projects, but also relatively complex projects. The data model of this project is listed below (as our business grows, this graph is also getting more complex day by day):
Another project is used on all the four portal websites: Pacific Online Comment System, http://cmt.pconline.com.cn . This is a high-stress system with 6,480,000 visits per day. There are millions of records in the database, and the records kept increasing about 10,000 per day. This proves that JDO is of great scalability and high performance. The data model is listed below:
There is yet another project which illustrates JDO’s Rapid-Development feature: Pacific Secondhand Trade System: http://es.pconline.com.cn . This project provides a web platform for users to sell or buy digital products freely. Though it’s not a big project, it does has some complexity. I want to point out that we developed it within only 5 man-days! Without JDO, I guess it would cost more than 1 man-month, and we’ll lose high performance and flexibility to easily add new functions according to new requirements. The data model is listed below.
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
