沒有策略性槍擊，沒有爭議性投票，在我們享受五一長假的過程中，JDO2.0規範的首輪議會投票結束了。
自從2004年4月20日JDO2.0規範的制定流程（JSR243）開動以來，JDO又開始回到人們的視線中，並且在五一假期結束之前，規範的制定委員會成員陸續地進行了投票，以表達各自的支持程度，目前投票已經全部結束。下面列舉一下投票結果，並在最後發表幾點個人愚見。
下面先列舉一下投票結果：
- 2004年4月30日，Sun公司投票支持JDO2.0，並發表了以下聲明：
本聲明是作爲對之前的一些投票聲明的迴應：
如果沒有JDO，那我們很值得爲Java是否應該在這一領域作出發展進行討論，其利和弊都顯而易見。不過既然JDO已經存在，並且已經有了足夠的用戶羣，並且他們希望JDO繼續發展下去。Sun作爲JDO規範的領導者，理所當然地感受到進一步發展JDO的緊迫性。
Sun相信JDO與EJB可以共存，我希望兩方面的專家組可以充分協調以避免不必要的規範重疊。而JDO是否應該歸入J2EE將是以後的論題。
基於目前JDO已經存在並吸引了相當多的Java開發用戶羣的目光的情況下，我想眼下最重要的是讓JDO在吸收用戶反饋和新需求的基礎上進一步發展。
- Graham - 2004年4月20日，Lea, Doug（紐約州立大學計算系） 投票表示支持
- 2004年4月20日，SAP AG 公司投票表示支持
- 2004年4月20日，Monson-Haefel公司, Richard 投票表示支持
- 2004年4月22日，IONA Technologies PLC 公司投票表示支持
- 2004年4月26日，Nokia Networks 公司投票表示支持
- 2004年4月26日，BEA公司投票表示反對，並發表下述聲明：
JDO目前屬於衆多的服務端數據持久性解決方案中的一種。在J2EE1.5已經將重點放在降低複雜性和增加易用性的情況下，我們不明白爲什麼還要繼續推出新版JDO，它的市場集中在有限的對象數據庫方面，此外，EJB3中也將會加入相似的一些（類似JDO的）改進。我們需要慎重考慮如何將JDO引入到其它一些新的領域，比如離散數據集支持等等，這樣的結合會有什麼後果。除非這些疑問得到闡釋，否則我們相信Java社區更應該將精力集中到更有競爭力的同類技術上去。 - 2004年4月26日，Apache Software Foundation 投票表示支持
- 2004年4月30日，Fujitsu Limited 投票表示支持
- 2004年4月30日，IBM投票表示反對，並發表下述聲明：
這份Java規範需求建議對JDO進行的擴展明顯地與其它已經啓動的JSR有重疊的地方。在Java社區已經開始推動J2EE簡化的趨勢下，我們並不希望建立重複的機制來完成同樣的功能。 - 2004年4月30日，Macromedia, Inc. 投票表示支持，並發表下述聲明：
儘管我們不希望看到的JDO與其它JSR的重疊確實存在，我們長期以來聽到的用戶的呼聲卻是他們願意自己去做決定如果處理這些重疊，而不是被平臺廠商強制限制。用戶往往希望自己選擇多種數據存儲方案中的一種，而不在乎爲這些重複的技術多花些時間和精力進行研究及選擇。我們支持JDO並不是因爲它是一種完美的構想，而是基於廣大用戶的長期開發實踐中的真實感受。 - 2004年5月2日，Caldera Systems 投票表示支持
- 2004年5月3日，Hewlett-Packard 投票表示支持
- 2004年5月3日，Apple Computer, Inc. 投票表示支持
- 2004年5月3日，Oracle 投票表示反對，並發表下述聲明：
JDO2.0與EJB3.0專家組正提出的輕量級存儲模型有衝突。讓兩種以上的規範來描述同樣的問題，而又使用不同的API、不同的存儲和事務語義、不同的映射定義和查詢機制，這樣無法使J2EE變得更簡單易用。EJB3.0的輕量級存儲方案將完美地滿足主流的企業Java應用開發者，包括那些現在對EntityBean模型提出批評的人。總之，既然EJB3.0已經在進展之中，另一個獨立的數據存儲標準是沒有必要的，它只會使眼下正想採納J2EE的決策者更加無所適從。
以上就是參與J2EE規範制定的16個武林幫派的投票結果（Borland棄權）。總的來說，是12票支持3票反對1票棄權，算是通過了。不過我們在反對的三票當中，可以琢磨出一些耐人尋味的東西：
Oracle在去年就對JDO一直懷恨在心，何解？Toplink也！因爲JDO直接威脅了非標準的Toplink的市場，甚至有相當多的呼聲要求Toplink出新版支持JDO的API，這樣當然影響到Toplink已經鎖住的衆多企業用戶。
IBM和BEA？多數中小規模的數據庫應用並不需要象EJB這樣複雜的體系，而JDO和其它一些輕量級的O/R映射技術正好填補這一空白，也許這一點決定了IBM和BEA的態度。兩者是當前EJB市場的絕對兩個大腕，安內必先攘外，在對EJB3.0進行積極支持並計劃以最快速度佔領市場的同時，碰到JDO這個可能會在企業數據庫開發市場分一杯羹的新技術，二者當然會暫時摒棄前嫌，合力對付這樣的異己。從這一方面來看，兩個公司相互支持的胸懷值得景仰，完全不象抗日日期的國民黨。話說回來，二者的態度最終還是爲自己的利益服務的，這也是一個商業公司的基本原則，不過象BEA所指的JDO僅限於對象數據庫範圍的應用，就純屬無稽之談了。
作爲規範領導者，Sun的態度不言而喻。而JDO與JSP2.0可以更好地結合，使得頁面製作人員可以簡單地在HTML編輯器中完成動態數據的結合，Macromedia自然是雙手贊成。
令人迷惑的是，一向主張在軟件開發中以人爲本的Borland此時爲何保持緘默？難道它最近的動向是.NET？這裏筆者也不便妄作揣測，只保持關注即可，一切的答案留給時間來公佈。
下面我們來看看爭論焦點的EJB3.0有些什麼樣的東西。
- 利用J2SE1.5提供的標註功能簡化EJB描述符。J2SE1.5確實太偉大了，可以對類、方法、字段等等進行嵌入式的註解，這樣，我們可以指望將來省掉所有的描述符、元數據之類的東西。儘管原來我們已經有XDoclet來幫助開發，但它對存儲映射細節的描述畢竟只存在於源代碼中，現在J2SE1.5的註解可以存在於編譯好的類二進制代碼中，真快哉！不過這一點完全不能證明JDO與EJB3.0發生了衝突，這只是另外一個範疇的改變，就象Intel又出了更高頻率的CPU，JDO和EJB都可以享受一樣，不能說明JDO與EJB發生衝突
- 提供更多的默認行爲，這樣可以有效減少配置工作量。這一點目前而言JDO已經比EntityBean做得好得多得多。
- 提供預定義的適配器類，減少開發人員需要實現的接口數目。在JDO中默認情況下你無需要實現任何接口，因此無法再減少。這方面可能不如EJB了？
- 更方便的JNDI處理。這是EJB本身的頑疾，這裏不再評論。
- 無狀態會話Bean的簡化。這與JDO無關
- 對CMP實體Bean以及相關的EJBQL進行更好的支持。這是關鍵所在，也是與JDO所謂的衝突最集中的地方。EJBQL和JDOQL也許是兩種不同的查詢規範，但一定要將二者合而爲一，還是將選擇權留給用戶？EJBQL只能靜態配置，如何動態化還未有指望，這方面可以說目前無法與JDO進行衝突吧。
- 減少一些必須捕捉的異常。一些與業務邏輯無關的異常將轉化爲動態異常。這方面，目前JDO的涉及數據庫操作的所有異常都已經被包裝爲動態異常，只有必要的情況下才需要捕捉。這也是EJB向JDO靠攏的一點體現。
- 性能調節的功能。這也與本文無關
- 其它一些專家組提出的改進。
綜上所述，我們看到JDO出現以來，Java數據庫開發方面有了可喜的變化，大家不必侷限於複雜的EJB，或者一些無法替代的現有O/R映射技術，而是有了新的，規範化的選擇。這些結果都影響着整個業界，包括EJB。希望Oracle、IBM、BEA這幾個Java界的巨頭能夠從用戶出發，從實際出發，認真面對這一改變。
最後需要說明的是，筆者本人是JDO的支持者，但希望聽到不同的聲音。歡迎大家對此發表評論。（在http://theserverside.com/news/thread.tss?thread_id=25695上已經有很多網友進行評論了）
本譯文的版權屬於筆者本人，但歡迎轉載，前提是註明出處和原作者。另外，歡迎在我的專欄中查看我的另幾篇文章，並提出寶貴意見！