Java 2007：新年展望
開源 Java 編程意味著由開發人員掌舵 —— 但他們將駛向何方？
|
|
級別: 初級
Elliotte Harold
(elharo@metalab.unc.edu), 副教授, Polytechnic 大學
2007 年 2 月 26 日
2007 年將是載入史冊的一年，Sun Microsystems 公司將于這一年在開源許可協議下發布 Java 開發包（JDK），從而放棄了對 Java? 平臺的統馭，將權力交給了 Java 開發人員社區！在本文中，Java 開發人員 Elliotte Rusty Harold 從各個方面預測了 Java 平臺的新方向，從腳本到 bug 修復到新語法。
2006 年又是 Java 平臺繁榮的一年。盡管遭遇了來自 Microsoft（C#）和腳本語言社區（Ruby）的沖擊，但 Java 語言仍然保持著其世界頭號編程語言的地位。同時，盡管 Java 6 的發布很值得慶祝，但比起宣布 Java 將在 GNU General Public License 下完全開源這一事件來說，卻不免有些黯然失色。Java 在 2007 年還能保持這種勢頭嗎？讓我們來看一下成敗的可能。
Java 平臺將成為開源平臺
2007 年上半年，Sun 將在一個開源許可協議下發布 Java 開發包（JDK）。解除 JDK 的禁錮對于 Java 開發人員社區來說是巨大的一步，它將在今后的十年中推動 Java 平臺的發展。
JDK 的質量將會顯著改善，因為程序員們不再僅僅報告 bug 并開始修復。Java Developer Connection 的 bug 報告將會包括對 JDK 中的問題部分的詳細分析，并提供修復的補丁。正如Linus 法則 所陳述的那樣，“只要給予足夠的關注，任何 bug 都是顯而易見”，即調試是可并行進行的。優化也是一樣。開源使兩者得以 并行。
分支項目
遺憾的是，設計并不是和調試、優化一樣可以并行完成的。清潔的 API 有時也需要有一只獨裁的手。但獨裁者的缺點是：有時他們知道在做什么，有時卻不知道。意圖成為獨裁者的各方面之間的競爭往往是發現問題最佳解決方案的惟一方式。
很少有公司能夠負擔得起這樣的代價，為一個產品開發多個獨立的實現，以便在多個產品中選定保留一個而摒棄其余的產品，但開源社區卻在朝這個方向努力。所以，您會在 Java 平臺的各個層次中發現分支產品：語言、虛擬機和庫。大多數的分支產品會失敗，但這沒什么。好主意會脫穎而出。一些分支產品會一直存在下去，一些會重新并入標準 JDK 中。明年的這個時候，分支產品與主流產品之間的差異也許不會很明顯，但這個過程會繼續下去。
Sun 會在幾個月后發布 Java 7，Dolphin 的一個早期的 beta 版，以此作為開端。Sun 無法發布更早的 JDK 版本，因為存在一些只有在 Dolphin 中才能解決的構建問題和許可協議問題。盡管如此，仍有望看到第三方著手進一步細分 Sun 的版本，來提供 Java 6、Java 5、Java 1.4，甚至更早版本的流行開源實現。
早期的一些探尋分支產品的人們可能會侵犯 Sun 公司的商標，收到 Sun 的律師寄來的討厭的律師信。我們需要一個通用的未注冊為商標的名字，讓所有人都能使用。我建議用 “J” —— 我希望沒人用單字母作商標。
開源項目從未消亡，只是有些褪色。就像之前的 Blackdown Project、GNU Classpath、Kaffe 和其他開源 JDK 項目一樣，他們的開發人員都轉向其他事情了。如果一個項目至今還沒有達到 1.0，那么恐怕以后永遠也達不到了。
期待 Java 7
Dolphin 不會在 2007 年發布。2008 年是更為現實的目標。那就是說，工作尚在進行中，它的一些功能也許會作為早期的標準擴展或至少作為 beta 登場。
遺憾的是，為一門語言添加功能遠比刪除功能要簡單得多。幾乎不可避免地，隨著時間的推移，語言不是朝著簡單的方向發展，而是越來越復雜，越來越讓人困惑。即使是那些單獨看起來很好的功能，在彼此疊加后也會出現問題。
令人遺憾，Java 社區沒有接受這個教訓，盡管這種失敗并無特殊性。但總有一些太酷又太讓人激動的新語法令語言設計者難以抗拒 —— 即便這樣的新語法不能解決任何實際問題。于是對 Java 7 的新語言功能就有了巨大的要求，包括閉包、多繼承和操作符重載。
我猜想在這一年結束前，會在 Java 7 beta 中看到閉包，也許還能看到操作符重載（有五成的把握），但不會出現多繼承。Java 中有太多東西是基于單個根的繼承層次。沒有可行的方式改進多繼承，使之適應這門語言。
目前有許多語法糖方面的提議，有一些有意義，有一些沒有。許多提議都專注于將像 getFoo() 這樣的方法替換為像 -> 這樣的操作符。
列表
最有可能的是使用數組語法來實現集合訪問。例如，不再采用下面這樣的代碼：
List content = new LinkedList(10);
content.add(0, "Fred");
content.add(1, "Barney");
String name = content.get(0);
|
而是編寫如下代碼：
List content = new LinkedList(10);
content[0] = "Fred";
content[1] = "Barney";
String name = content[0];
|
另一種可能性是：允許為列表使用數組初始化程序語法。例如：
LinkedList content = {"Fred", "Barney", "Wilma", "Betty"}
|
這兩項提議都可以在不改變虛擬機（VM）的前提下由編譯器稍顯神通即可實現，這是任何修訂過的語法的一項重要特征。這兩項提議都不能使任何現有的源代碼失效或重定義現有的源代碼，對于新語法來說，這是一個更為重要的問題。
真正能夠影響開發人員生產力的特性功能應該是用于管理表、樹和映射表的內置原語，比如在使用 XML 和 SQL 時遇到的那些。JavaScript 下的 E4X 項目和 Microsoft 的 Cω 和 Linq 項目是實現這一想法的先驅，但可悲的是，Java 平臺似乎錯過了這個機會。如果有人想要通過編譯器來玩一個潛在的救場的游戲，這里是一個不容錯過的好地方。
屬性
很可以還有一些針對屬性訪問的語法糖。一個建議是使用 -> 作為調用 getFoo和 setFoo的縮寫。例如，不再使用如下代碼：
Point p = new Point();
p.setX(56);
p.setY(87);
int z = p.getX();
|
而是使用如下代碼：
Point p = new Point();
p->X = 56;
p->Y = 87;
int z = p->X;
|
也有人建議用另外一些符號來代替 ->，包括 . 和 #。
將來，您有可能必須將 Point 類中的相關字段顯式地標識為屬性，如：
public class Point {
public int property x;
public int property y;
}
|
我個人對此并未產生什么深刻的印象。我寧愿 Java 平臺采納一項更為激進的方法，讓我們可以真正地使用公共字段。然而，如果將 getter 或 setter 定義為與字段相同的名稱，然后讀寫字段就會自動地分派到相應方法中。這樣做所使用的語法更少，也更加靈活。
隨機精度算法
|
|
非操作符重載
值得一提的是，對標準數學符號的重用不同于 操作符重載，至少不是在 C++ 中引起問題的那種重載。加號和其他操作符在任何程序中都具有明確的意義。無論在哪一個程序中，它們的意義都不會有所更改。對于相似的操作重用相同的語法讓代碼更易于閱讀。若重新定義語法，使之在不同的程序中有不同的意義，代碼就會較難理解。
|
|
另一項將方法替換為操作符的建議致力于 BigDecimal 和 BigInteger。例如，目前您不得不像這樣編寫不限精度的算法：
BigInteger low = BigInteger.ONE;
BigInteger high = BigInteger.ONE;
for (int i = 0; i < 500; i++) {
System.out.print(low);
BigInteger temp = high;
high = high.add(low);
low = temp;
};
|
寫成這樣會更清晰：
BigInteger low = 1;
BigInteger high = 1;
for (int i = 0; i < 500; i++) {
System.out.print(low);
BigInteger temp = high;
high = high + low;
low = temp;
};
|
這項建議似乎無關緊要，但它可能會導致過度使用這些類，進而導致尚不成熟的代碼中性能降低。
將 JAM 從 JAR 中分離出來
Java 7 會撫平 Java 開發人員長久以來積聚的憤怒：各種各樣的類加載器和相關的 classpath。Sun 公司在 Java Module System 這個問題上經受了又一次打擊。數據將存儲到 .jam 文件，而不是 .jar 文件中。這是一種 “superjar”，它包含了所有的代碼和元數據。最重要的是，Java Module System 將首次支持版本，所以可以說一個程序需要 Xerces 2.7.1 而不是 2.6。它也允許指定依賴項；例如，可以說一個 JAM 程序需要 JDOM。它也要允許在加載一個模塊時不必加載全部模塊。最終，它要支持一個集中式的存儲庫，其中要能提供多個不同的 JAM 的不同版本，應用程序能夠從中挑選所需。如果 JMS 適用，jre/lib/ext 將會成為過去時。
包訪問
我也希望 Java 7 能夠稍微放松一下訪問限制。子包也許能夠看到上層包里的包保護字段和類方法。也就是說，子包也許能夠看到上層包里明確聲明友好性的包保護成員。不論用哪種方式，將應用程序分割成多個包都會變得簡單的多，也會顯著地改善可測試性。只要子包中含有單元測試，就不必使用公共方法去進行測試。
文件系統訪問
自從 1995 年開始，文件系統訪問就成為 Java 平臺的一個主要問題。十多年后，還是沒有可信賴的跨平臺方式來執行如復制或移動文件這類基本操作。處理這個問題是過去至少三個版本的 JDK（1.4、1.5 和 1.6）的公開問題。遺憾的是，為了迎合不怎么普遍卻更具誘惑的操作，如內存映射 I/O，有些乏味但卻很必要的 API 被擱到了一邊。JSR 203 可能會最終解決這個問題，給我們一個可行的、跨平臺文件系統 API。工作組也許會再一次對其無比崇尚的真正的異步輸入/輸出文件系統這個相對不重要的問題上花費過多時間，從而讓該 API 再一次束之高閣。下一年的這個時候我們就會知道。
實驗
無論做出什么樣的改變，如果它們首先是在開源社區里實現，那么都是令人愉快的，所以我們只要看一下真正的區別有多大或多小。為此，Sun 公司的 Peter Ahè 開始了 java.net 上的 Kitchen Sink Project。目標是要分別地分派和指定 javac 編譯器，來測試像這樣的許多不同想法。在博客里寫寫這些可愛的功能是一回事；但真正制造運行的代碼則全然是另一回事。
客戶機 GUI
盡管許多人還沒注意到，但 Java 平臺真正出現在桌面上到現在已經有四五年了。已經有幾個優質的桌面應用程序是用 Java 代碼編寫的，包括 RSSOwl、Limewire、Azureus、Eclipse、NetBeans、CyberDuck 等等。這些應用程序幾乎用了每一個可用的 GUI 工具包來編寫，包括 Swing、AWT、SWT，甚至是平臺原生的工具包，如 Mac OS X 的 Cocoa。我看不出下一年會有哪個工具包在眾多工具包中勝出，盡管 Swing 在制造一些保留本色的應用程序方面似乎比其他工具包表現得更為出色。
用 Swing 進行開發仍是相對挑戰的，但隨著 Swing 應用程序框架的到來，這種情況也許會在下一年得到改善。這一框架目前尚在 Java Community Process 中作為 JSR 296 開發。下面是 JSR 關于此的描述：
編寫良好的 Swing 應用程序試圖為啟動和停止，以及管理資源、行為和會話狀態的代碼使用相同的核心元素。新應用程序從頭開始創建所有這些核心元素。Java SE 不支持構造應用程序，這常常讓開發新手們感到有點茫然，特別是在他們打算構建一個規模遠超于 SE 文檔中提供的例子的應用程序時。
通過定義 Swing 應用程序的基本結構，這項規范（最終）會添補該空白。它會定義一小套可擴展的類或 “框架”，用于定義相對于大多數桌面應用程序較普遍的基礎設施。
Swing 應用程序框架應支持典型應用程序中的大多數東西，允許開發人員恰在一些自定義的點處插入，如啟動和停止時。在啟動和停止之間，它將處理 windows 的保存和恢復，以及應用程序的其他部分。最后，它將允許開發人員編寫在 Swing 事件分派線程外運行的異步行為。
改善 JavaBeans 以及所有依賴它的東西（包括 Swing）的工作尚在繼續。JSR 295 正在定義一種將 bean 綁定到一起的標準方式，這樣，對一個 bean 的修改就會自動地反映到其他的 bean。例如，一個 GUI 網格 bean 會在其相關數據庫 bean 改變時自動更新。
最終，JSR 303 正在實現一門基于 XML 的驗證語言，來聲明式地指定任何給定的 bean 將取什么值。int 屬性將必須介于 1 到 10 之間，或者 String 屬性必須包含一個合法的電子郵件地址。如果幸運，這一切都將在年底以 beta 形式提供，并將在來年的 Java 7 中按時完成。
作為桌面語言的 Java 平臺
一些程序員們選擇用 Java 代碼編寫他們的桌面應用程序是因為它們偏愛這門語言，但大多數程序員則是被多平臺轉換這一強烈的渴望所驅動。對 Java 平臺作為桌面語言的興趣于是就同非 Microsoft 桌面的數目緊緊地聯系了起來。讓我們認為 Java 編程會在來年出現在三大主流桌面上。
Windows
Swing 在下一年會繼續對其類似 Windows 的外觀作出小的改進，尤其是轉換到開源開發這一部分。結果，純 Java 程序如 LimeWire 甚至會比在 Windows 下看起來更加具原生感。但開發原生 Windows 應用程序所選擇的語言仍是 C#（還有一些 C 和 C++ 的追隨者），而開發框架會選用 .NET。Java 代碼不會對 Windows 生態系統造成任何顯著打擊。
Macintosh
像 Microsoft 一樣，Apple Inc. 也使用了相當多被拋棄的 Java 代碼。Apple 公司喜愛 Objective C 和 Cocoa，但最后的結果是相同的：只用 Mac 的開發人員會繼續減少 Java 代碼，而選擇 Apple 偏愛的語言和環境。
積極的一面是，盡管 Apple 不再在其私有的 API（如 QuickTime 和 Cocoa）中支持 Java 代碼，Apple VM 已經比前些年改進了不少。Apple 的 Java 6 移植版不久就會發布。它不會是開源的（不同于 Sun 的 JDK），但開源程序員們還是會著手修補它的 bug。
Linux
GPL 許可協議將使這成為可能，即將 Java 代碼綁定到最純的開源 Linux 發行版中，這將使 Java 平臺成為 Linux 開發中更為吸引人的語言。如果這些在五年前發生的話：Linux 社區將不會不得不掙扎于使用 C 語言，而 Mono 也不會成為必要。
已經有了針對 Gnome 和 KDE 的 Java 綁定，所以希望這些會在接下來的一年里吸引更多人的關注。也期望至少有一個即將進行的開發 Linux GUI 程序的主要項目使用 Java 語言而不是 C、C++ 或 C#。
Ruby 取勝
|
|
臃腫的軟件
JavaScript 已經和 JDK 6 綁定到了一起。其他語言也許會添加進 JDK 7。我覺得那樣會有點臃腫。首先，Sun 公司絕不會加入一門語言就停下來。如果它選了 BeanShell，擁護 Groovy 的家伙也會要求加入。如果加入了 Groovy，用 Ruby 的家伙也會堅持要加入。如果 Ruby 加入，還能忽略 Python 嗎？標準 JDK 已經太龐大了。支持多種腳本語言是一回事，但將它們綁定到一起還是同一件事嗎？策略性的改進應該是支持所有這些語言，但一個也不綁定進來。
積極的一面是，Sun 公司正在研究減小初始下載尺寸和減少應用程序啟動時間的方法，尤其是 applet 和 Java Web Start 應用程序?？赡艿姆椒ㄊ?，將大量的類庫放到服務器上或放到速度較慢的后臺線程中，只下載需要的部分。
|
|
如果我們只說一門語言，世界將會索然無味。盡管 Java 平臺是開發成熟應用程序的絕佳選擇，但它從來就不適應于小程序或宏。Java 6 意識到了這一點，它添加了 javax.script 包實現，以便和腳本語言（如 BeanShell、Python、Perl、Ruby、ECMAScript 和 Groovy）進行互操作，也添加了一項 invokedynamic 虛擬機指令來允許將動態類型語言直接編譯為 Java VM。
2007 年，我將寶押在 Ruby 上，盡管它并不是我個人的最愛。對于我來說，Python 代碼似乎比 Ruby 代碼更簡潔更易于理解，我認為大多數 Java 程序員都會這樣認為。然而，Python 出來的不是時候。許多開發人員不得不在學習 Python 代碼還是學習 Java 代碼間作出選擇，而多數人選擇了 Java 代碼。既然他們終于弄懂了 Java 語法，又打算在工具箱中添加另一門語言，他們想要的是明天的語言，而不是昨天的語言，而那門語言似乎就是 Ruby。更重要的是，Ruby 的 Ruby on Rails 是一個絕對殺手級的應用程序。它的簡單性對于多數覺悟了的 Java 企業版（Java Enterprise Edition，JEE）開發人員來說具有難以置信的魅力。
除了 Rails，比起其他腳本語言，JRuby 項目和現有的 Java 代碼很好或更好地集成到了一起。事實上，JRuby 也許會超越標準 Ruby 分布，并成為 Ruby 程序員們更偏愛的平臺，而不止是 Java 程序員們將 Ruby 作為第二種選擇。這很好。Python 程序員們會這樣反對：他們這些年來已經將 JRuby 最好的方面加入到 Jython 中，他們是對的，但我討論的是 2007 年將 發生什么，而不是應該 發生什么。這很不幸但卻是事實：Ruby 獲得了契機，而 Python 沒有。
其他腳本語言會被逐漸逐出界外。Perl 太過時了，不能很好地適應現代應用程序。Groovy 缺少明確的視角，還趨向于將計算機科學的時髦用語凌駕于可用性和熟悉性之上，這讓它深受其苦。BeanShell、Jelly，還有半打其他語言可能都從未吸引過超過一個的稱心追隨者。來年的這個時候，到處都會是這樣的吶喊：Ruby 將成為 Java 程序員們首選的腳本語言。
集成開發環境（IDE）會變得更好
一批垂死的 IDE 真正點燃了 2006 之火，再一次證明競爭是好事。由于 Eclipse 造成的窘境，Sun 將一些能量和資源注入到 NetBeans 當中，最終開始了一場貌似激烈的競爭。通過采取一些措施，到 2006 年底，NetBeans 甚至超越了 Eclipse。它針對設計 GUI 具有卓越的原生化外觀和出色得多的工具。它所不具有的是 Eclipse 社區。相比 NetBeans，更多的插件和第三方產品是基于 Eclipse 的 —— 至少從量上更多 —— 并且這種趨勢僅呈加速之勢。
來年，Eclipse 會努力開發 3.3 版，應于 2007 年發布。Sun 也可能成功地將 NetBeans 6 公諸于世。這兩個版本都不太可能是重要的版本：它們只是關注于添加這里或那里的小功能、修復 bug 和簡化用戶界面（盡管可能還沒有做到應該要做的那么多）。
NetBeans 可能將繼續贏得 Eclipse 的市場份額。這是從很早以前就開始了的，這方面還有更大的增長空間。（Sun 無情地推動 NetBeans 和 JDK 下載并沒傷害到任何一個）。到本年度結束時，兩種 IDE 也許將瓜分這個市場，平分天下。
同時，自信滿滿的 IntelliJ IDEA 用戶將繼續疑惑于這一團混亂的場面。他們的信念是：IntelliJ IDEA 是最好的 Java IDE。盡管如此，大多數用戶不會對 500 美元的標價視而不見，因此其市場份額將繼續在 5% 上下波動。
Java 企業版
沒有哪部分 Java 編程像 JEE 這么成功，也沒有哪部分 Java 編程像 JEE 那樣招致如此多的斥責。它是一門每個人都喜歡去討厭的技術。它復雜、費解并且是重量級的。沒有哪部分 Java 編程有這多么第三方努力將其整個替換或部分替換：Spring、 Hibernate、Restlet、aspects、Struts …… 等等。雖然如此，幾乎每一個招聘 Java 程序員的商家都要求其有 JEE 經驗，因此 Sun 確實是正確的。
在企業級領域里，我能看到的全部趨勢就是簡單。大塊頭的框架出局；小而簡單的加入了進來。隨之增長的是，客戶拒絕大塊頭的 JEE 棧部分，這種趨勢還在繼續。作為替代的是，客戶轉向了像 Spring 這樣更簡單的框架或者完全脫離 Java 平臺而投向 Ruby On Rails。對于更簡單、更易理解的系統的需求也驅動著對面向服務架構（SOA）和具象狀態傳輸（Representational State Transfer, REST）的興趣。
我們能夠預料出，朝著簡單發展的趨勢在 2007 年將會延續。許多對 Rails 留下印象的人正試圖在其他語言上復制它的成功，比如 Python (Turbo Gears)、Groovy (Grails) 以及 Java (Sails)。這其中的某個有可能成功，但它們如果不提出一些強有力的新舉措的話，就不會取得成功。因此，企業仍將加載他們已有的框架：SOA、REST 和 Rails。
Java 微型版（Java Micro Edition, Java ME）
將視線從最大平臺移到最小平臺上來，我們能期待嵌入式世界帶給我們什么？多年以來，Java 平臺已經在小設備上取得了相當大的成功，而 2007 很可能會以這一成功為基礎。首先，關注一下移動信息設備描述（Mobile Information Device Profile，MIDP） 的第 3 版，來利用當今更為強大的設備的功能。特別是，我們應該很快就能在一個虛擬機上運行多個 MIDlet，包括在后臺運行一個或多個。同樣也關注一下加密記錄管理系統（RMS）存儲和 IPv6 支持。
Java ME 的可擴縮的 2D 矢量圖形（Scalable 2D Vector Graphics, SVG）API 2.0 當前正在開發中，它應擴展在許多設備中的動畫功能。除 SVG 動畫之外，它也將支持流式音頻和視頻。如果移動網絡開放，這是相當重要的 —— 想想在手機上的 YouTube。（當然，如果網絡開放，那就只是沒人愿意看的兩英寸的公司廣告。在這點上，我對美國的情況持悲觀態度，而在歐洲也許會更有趣。）
移動開發者也能期望本年推出第一款支持 Java ME 的 XML API 的手機。此 API 是 SAX、DOM、 StAX 和 JAXP 的一個精選子集，設計它是為了適應內存受限的手機。許多人認為真正的 XML 不適合手機 —— 他們是對是錯今年就能見分曉。
盡管好事連連，Apple 的 iPhone 仍對 Java 平臺（作為移動電話開發平臺）構成了一個主要的威脅。iPhone 已經是這個星球上最火爆、最有魅力的手機，它已經發布了六個月。問題在于它將成為一個相對封閉的平臺，甚至按手機網絡標準也是如此，并且它沒打算運行 Java 代碼。無需多說，對于任何試圖向手機、PDA 和個人通訊設備推銷第三方應用程序的人來說，這都是一個恐怖的消息。
結束語
由于 JDK 的開源，2007 注定成為自互聯網炸彈（dot bomb）以來 Java 編程界最令人激動的年份。截至目前，Java 平臺一直被 Sun 公司的目標和投資能力所制約，但這種情況即將改變。有了開發者社區掌舵，我們有望看到 Java 編程全方位發展，而這種發展很可能突然出現。開發人員將使用 Java 代碼（以及針對 Java 代碼）完成比以往更多的任務。桌面、服務器以及嵌入式：一切都會加速！是的，在這個過程中會有一些重大的失敗，但失敗也是樂趣的一部分！好的想法將脫穎而出，不好的將被淘汰。如果您對 Java 平臺有任何不滿意，或者有一直迷惑的地方，啟動您的 IDE，開始改造吧！
女士們、先生們！啟動您的編譯器吧！
參考資料
學習
獲得產品和技術
-
下載 Java 7
：開放源碼的書面文件尚未簽定，但您仍然能通過使用 Java 7 的源碼取得領先的地位。
-
Sails
：一個用 Java 代碼編寫的 Rails 的翻版。
討論
關于作者
|
|
|
|
|
Elliotte Rusty Harold 來自新奧爾良，現在他還定期回老家喝一碗美味的秋葵湯。不過目前，他和妻子 Beth 定居在紐約臨近布魯克林的 Prospect Heights，同住的還有他的貓咪 Charm（取自夸克）和 Marjorie（取自他岳母的名字）。他是 Polytechnic 大學計算機科學的副教授，他在該校講授 Java 和面向對象編程。他的 Web 站點 Cafe au Lait 已經成為 Internet 上最流行的獨立 Java 站點之一，它的姊妹站點 Cafe con Leche 已經成為最流行的 XML 站點之一。 他最近編著的一本書是 Java I/O, 2nd edition。他目前在從事處理 XML 的 XOM API、Jaxen XPath 引擎和 Jester 測試覆蓋率工具的開發工作。
|