Sun 的 Java 和 XML API：孰功孰過？

dongmiao158

[color="#996699"]Brett D. McLaughlin, Sr.
(
[email=brett@newInstance.com?subject=Sun%20%E7%9A%84%20Java%20%E5%92%8C%20XML%20API%EF%BC%9A%E5%AD%B0%E5%8A%9F%E5%AD%B0%E8%BF%87%EF%BC%9F&cc=dwxed@us.ibm.com][color="#5c81a7"]brett@newInstance.com[/email]
), 作家兼編輯, O'Reilly Media, Inc.
Brett
McLaughlin 從 Logo 時代就開始使用計算機。（還記得那個小三角嗎？）近年來他已經(jīng)成為 Java 技術和 XML
社區(qū)最知名的作家和程序員之一。他曾經(jīng)在 Nextel Communications 實現(xiàn)過復雜的企業(yè)系統(tǒng)，在 Lutris
Technologies 編寫應用程序服務器，最近在 O'Reilly Media, Inc. 繼續(xù)撰寫和編輯這方面的圖書。在他的新書
Head Rush Ajax 中，Brett 與暢銷書作家 Eric 及 Beth Freeman 為 Ajax 帶來了獲獎的創(chuàng)新方法
Head First。他的上一本書 Java 1.5 Tiger: A Developer's Notebook 是第一本可獲得的關于最新版本 Java 技術的書籍，而他的經(jīng)典著作 Java and XML 仍然是在 Java 語言中使用 XML 技術的權威圖書。


回顧古老的 JAXP


對
于剛接觸 Java 和 XML 的程序員（或者通過 Sun 和 J2SE 才接觸到 XML 的程序員）來說，都有必要簡要回顧一下早期的
JAXP。那時，JAXP 是 Java 和 XML 領域中排行第三的 API，風靡程度僅次于 SAX（Simple API for XML）和
DOM（Document Object Model）。JAXP 的目標非常簡單：使 SAX 和 DOM 的使用更加簡單，尤其是在供應商中立領域。


JAXP 是一個包裝器 API


最初，JAXP 的目的僅僅是向 SAX 和 DOM 提供便利性和供應商中立性。根據(jù)這一點，JAXP 從未想過要替代 SAX 或 DOM；事實上，JAXP 在其早期版本中擁有一些方法，getXMLReader() 和 getDOMParser() 就是其中的兩個。 顯而易見，這些方法的存在表明 JAXP 的作者希望 開發(fā)人員使用 JAXP，然后操作底層的 SAX 和 DOM 實現(xiàn)類。


還
有一點值得注意，雖然 JAXP
在這些年中不斷地加入大量的功能，但是這兩個方法從未修改過。有的人會說這不過是出于向后兼容性的考慮，不過這確實反應了 JAXP 從未打算將
SAX 或 DOM 取而代之。JAXP 只不過是將它們封裝起來，這樣開發(fā)人員就不必使用大量特定于供應商的代碼來調用 SAX 或 DOM了。


JAXP 提供了供應商中立性


在早期的 Java 和 XML 編程中，存在大量
的 XML 解析器（最初的 Xerces 和 XML4J，Sun 公司的 Crimson，Oracle 公司的 XML
解析器，以及一些如今人們從未聽過的解析器。）當我們編寫一個與 XML 協(xié)作和交互的應用程序時，需要將 SAX 和 DOM API
連接到這些解析器實現(xiàn)，通常所使用的方法是將解析器類名告知 SAX 或 DOM，有點類似如下的方式：


     
         
            
         
     
     
             Parser parser = new org.apache.xercers.parsers.SAXParser();
              
                 



注意：我有意使用了較舊的 SAX Parser 接口；它是舊的 SAX 1 解析類，在 JAXP 成為問題的時期所有人都在使用它。


JAXP 引入了一個 javax.xml.parsers.SAXParserFactory 系統(tǒng)屬性，它允許我們指定解析器工廠實現(xiàn)（工廠中提供了想要使用的解析器）�？梢酝ㄟ^一個 System.setProperty() 系統(tǒng)屬性指定工廠，也可以通過某些位置下的 jaxp.properties 文件來指定（本質上說，即應用程序類路徑中的任何位置）。


無論采用何種方式指定這一屬性 — 或者其對應的 DOM 屬性 javax.xml.parsers.DocumentBuilderFactory — 都需要避免在解析代碼中出現(xiàn)任何類名。這也是 JAXP 存在的首要原因：防止將此類信息直接放入代碼。可以通過改變屬性值來方便地修改各種屬性，或者甚至建立多個 jaxp.properties 文件用于不同的解析器實現(xiàn)，并且在需要時對它們進行切換。




     
         
            
         
     
   

   

     
         
            
         
     
   


            
                 
                     
                        
                        
                     
                 
               

   
                 



JAXP 現(xiàn)狀


對
于 Sun 公司推出 JAXP
的最初目的，您可以執(zhí)有自己的看法，甚至可以否定其價值，但是此時這已經(jīng)沒有什么實際意義了。真正具有現(xiàn)實意義且值得討論的是：JAXP
如今的角色是什么？以及人們正在如何使用它？如今，所有的 Java 發(fā)行版毫無例外的將 JAXP 囊入其中，顯然 Java EE（J2SE
and Java Platform, Enterprise Edition 5）、Java Platform 和 Java ME（Java
ME）不包括在內，大約 95％ 的 Java 和 XML 開發(fā)人員都在使用 JAXP。


JAXP 作為 SAX 和 DOM 的替代


隨
著時間的推移，JAXP 已不再封裝 SAX 和 DOM，而是在逐步取代它們。現(xiàn)在我們需要記住，JAXP 本身并不是一個真的解析 API（在需要
SAX 或 DOM 解析器運作的情況下）。因此 JAXP 永遠都無法從功能上取代 SAX 或 DOM；然而，它可以在實際應用中 取代它們，開發(fā)人員完全可以停止使用 SAX 包（org.xml.sax）或 DOM 包（org.w3c.dom）中的方法或類。


要
驗證這點，其中一個方法就是詢問開發(fā)人員。因為 Sun 公司在促銷（可以這樣理解）自己的 API，而且 JAXP 與當前版本的 Java 技術
“綁” 在了一起，所以許多開發(fā)人員都是通過 JAXP 接觸 XML 的。自然而然，他們開始學習使用 JAXP，甚至大多數(shù)已經(jīng)牢固掌握 SAX
和 DOM 的開發(fā)人員也覺得 JAXP 更加好用。事實上，許多開發(fā)人員都完全沒有意識到 SAX 和 DOM 是 JAXP 的基礎！


所有這些使 SAX 和 DOM 在 JAXP 的光彩下逐漸離開人們的視線。對 ContentHandler 和 DOMImplementation
的談論已成了昨日黃花，或者至少是相當高端的 Java 和 XML 程序員才會知道這些。這甚至與 5 年之前的相互抗衡的情形迥然不同，那時
JAXP 仍處于演化和起步階段，除了 JAXP 之外開發(fā)人員通常至少會對 SAX 和 DOM 中的一種偏愛有加（許多情況下是兩種）。


是添加了更多功能，還是維持原狀？


然而，比起相互抗衡更加重要的一點是：甚至有人只
使用 JAXP — 而不是直接使用 SAX 和 DOM，或使用 JAXP 附帶的那些 API — 這極大地限制了 XML 編程和解析功能。因為
JAXP 確實只是一個包裝器 API（無論人們如何使用它），它無法使用 SAX 和 DOM 提供的任意選項。雖然我們可以在 JAXP
上設置解析器的特性和屬性，并能處理內容和基本的錯誤處理，不過 SAX 尤其提供了大量的與語法相關的事件（DTD 和
模式）和更高級的詞法事件（如處理指令）。訪問這些事件的惟一方式是直接操作 SAX XMLReader 接口。


請記住，我并不提倡將 JAXP 一棒子打死。我們可以將 JAXP 用作它的原始目的 — 訪問解析器，而不必直接處理代碼中的供應商解析器類 — 然后使用 JAXP 的 getXMLReader() 訪問獲取 SAX XMLReader 接口。這樣，便可以輕松地直接操作 SAX — 但是所有這些需要我們首先了解如何操作 XMLReader 接口。


所
有這些，我們可以看出 JAXP 表面是添加了一些功能 — 供應商中立性，一些便利性和幫助器方法 —
但是實際上可以移除這些內容。如果開發(fā)人員過分依賴于 JAXP（這已經(jīng)成為了目前的問題），那么他們將非常容易忘記或甚至沒有意識到 JAXP
并未公開 SAX 和 DOM 中的大量功能。因此，雖然 JAXP 本來是用于提供功能，但是它實際上減少了 Java 和 XML 程序員的工具。


開放源碼問題？


我
將這個問題留在最后討論，其主要原因是它涉及到道德、合法性和各種會讓大多數(shù)程序員覺得枯燥和無聊的內容。而且這似乎還不夠，開放源碼還將哲學牽扯進來。
總之，我想知道 Sun — 雖然一直將法律放在首位 — 是否沒有違反法律精神（開放源碼和社區(qū)方面）。當他們將 SAX API
作為基石，然后開始在 JAXP 中添加功能，我想知道他們?yōu)槭裁礇]有將這些功能融入到 SAX 中去？在 JAXP
中添加方法調用這些新功能（就是他們的大多數(shù) API）也是完全可行的。但是這些功能就不能作為整體提交給 SAX API 嗎？


事
實上，如果 JAXP 的實用性是與 Sun
希望我們相信的那樣（說實話，我沒有必要討論其實用性），那么為什么他們不將這些功能提供給我們。我們至少有時會傾向于單獨使用 SAX，而不需要
JAXP。為了避免任何可能的混亂，我們仍然會選擇使用 Java 技術，因此 Sun 公司通過 SAX（而不僅僅是
JAXP）將這些功能提供出來并不會失去任何業(yè)務（這甚至是一個笑話，就像 Sun 不再賣 Java
技術）。還有，這個問題雖然相當細微，但是卻值得思考：如果 JAXP 提供了如此巨大的價值，難道其中一些價值就不能分給底層的 API
嗎？JAXP 將仍然受益于在 SAX 和 DOM 之間輕易轉換，不過對于 XML 社區(qū)來說將會是一個很大的欣喜。




     
         
            
         
     
   

   

     
         
            
         
     
   


            
                 
                     
                        
                        
                     
                 
               

   
                 



結束語


我并不想在這里發(fā)表激昂的言論（不過我不會介意一些讀者在
[color="#5c81a7"]討論論壇
上這樣做），但是我仍然要質疑 JAXP — 和其他一些同一性質的 Sun API — 以及它從一個包裝器 API 演化成為 “全能” 解析器
API。我認為 JAXP 埋沒了 SAX 和 DOM 自身的價值，卻沒有換回任何有意義的價值。我很樂意 Sun 將 JAXP
作為針對供應商中立的一個封裝層，并將解析方法和行為穩(wěn)固地留在 XML 解析器和 API 供應商的領土中。


     
         
            
            
         
     
   

?   

當
然，Sun 公司并未向我致電征求我的意見，而且 Scott McNealy 肯定也從未聽過我的名字，因此對于 Sun 的做法我們也無能為力
。然而，設想如果您是一名 Java 和 XML 程序員，這至少會讓您對 JAXP 的使用產(chǎn)生疑問 —
這就是他們的意圖。如果程序員還要（重新）學習 SAX 和 DOM 的話，我們就會明智地開始使用
JAXP，事實上是為了更好地編寫應用程序，因為我們能夠在較低等級操作 XML 文檔，而且能夠更加游刃有余。然后，甚至連 Scott
都會注意到我們所編寫的優(yōu)秀應用程序，難道不是嗎？因此您告訴我：這有什么意義嗎？
               
               
               

本文來自ChinaUnix博客，如果查看原文請點：http://blog.chinaunix.net/u3/110548/showart_2162197.html