不要再以為 java 只能拿來設計網(wǎng)頁上的動態(tài)圖形，其實 Java 是一個功能完備的程式語言，而且是當今許多程式員的第一選擇。因為 Java 語言具備清楚的架構、提供動態(tài)記憶體治理、 渾然天成地整合了 Web … 等優(yōu)點，使得 Java 開發(fā)程式過程所需要的時間較許多其他開發(fā)工具少得多。 暢銷作家 Elliotte Rusty Harold 最近出版的 一本書《 Java I/O 》 具體地帶我們深入了解 Java I/O 的內部奧妙及其用法。我們特地邀請他接受我們幾分鐘的訪談， 針對 Sun 公司所規(guī)劃的 Java I/O 的方向。

Wayner：哪一類的 Java 程式員該對 Java I/O 相關議題感愛好？

Harold：所有的 Java 程式員都該對 Java I/O 感愛好。幾乎所有的程式多多少少都會牽涉到 I/O， 盡管其目的各有千秋。然而教科書上的 IO 范例經(jīng)常只局限在命令列參數(shù)（command line arguments）和 System.out.PRintln()，卻忽略了真正的程式常需要讀寫檔案、讀寫網(wǎng)路、資料加密解密、從串列埠 （serial port）收送資料、和資料庫溝通 … 等。我們通常可以透過觀察程式員駕馭 I/O 的能力 來判定他的專業(yè)程度，離 System.out.println() 越遠的程式員程度越專業(yè)。

Wayner：在許多人既定的印象中，Java 是用來寫網(wǎng)頁上 applet 的工具，但其實 Java 是一個功能完整的程式語言。你認為 Java 和 C++ 此二功能完整的程式語言在 I/O 方面的比較上如何 ?

Harold：毫無疑問地，Java 的 I/O 工具比 C/C++ 更加洗練、強大、且輕易使用。 C/C++ 以及其他許多語言都假定讀寫的資料來自 1970 年代的陽春終端機之類的設備， 跟不上時代的腳步，現(xiàn)代的 C/C++ 程式員也就深為此所苦。Java 是第一個拋棄此包袱的主流程式語言。Java 的設計者 早就意識到檔案的讀寫、網(wǎng)路的連結、以及和串列埠的溝通相當重要，絕非資訊系一年級 學生的程式作業(yè)「讀入一個數(shù)目，輸出開根號的值」可以比擬的。

可惜的是，因為 Java I/O 所采行的結構相當不同於以往，使得許多程式員不知道它其實 很簡單卻也很強大。從我的學生們的反應、許多網(wǎng)路討論區(qū)、以及郵寄討論信件中，我發(fā)現(xiàn) 大多數(shù)的人一開始就問了不該問的問題。比方說，常有人問如何從 console 讀取一個數(shù)字。 其實，他們不應該一開始就和 console 打交道。

學生總是在問 Java 有沒有和 C 的 scanf() 類似的用法，我覺得這都要責怪教授沒有好好教。 你瞧瞧，市面上一堆介紹 Java 的書時常一開始就教讀者如何用 Java 寫出等同於 C 的 scanf() 和 printf() 等功能。 我覺得這個現(xiàn)象背後的因素可能為：「作者根本不了解 Java，非凡是 Java I/O」，或者「作者直接 沿用二十年不變的 Pascal 陳年舊例，懶得花心思改寫」。現(xiàn)在已經(jīng)是 1999 年了，使用者介面應該是 圖形模式（ GUI）而非文字模式（ console ）。我們有必要在資訊系的課程中向學生介紹現(xiàn)代化的 GUI 程式設計方式。 現(xiàn)在，我正在教研究生 Java 入門課程，班上的學生中不超過百分之十有 GUI 程式設計經(jīng)驗。

當然，使用者介面是 GUI，不表示傳統(tǒng)的 I/O 方式不再重要。但是一旦你棄 console 不用， 你可以設計出更清楚的 I/O 介面，可輕易地支援檔案、網(wǎng)路 … 等，使用 Java 就有這樣的好處。

Wayner：至於那些 Web 的 applet 設計者來說，Java I/O 對他們有何影響呢？

Harold：Java 的安全機制嚴格地限制了網(wǎng)頁瀏覽器內的 applet 所能進行的 I/O 動作。 目前主要的瀏覽器尚未支援 Java 2 的安全模型，所以純粹只是「理論上可以， 實際上不行」。而且，大多數(shù)使用者不會因為希望網(wǎng)站設計人員較輕松就額外放寬 applet 的權限。 所以，一般 applet 使用到的 I/O 主要是和原伺服器之間建立網(wǎng)路連線、或使用 object serialization、 或 RMI。

Wayner：當微軟開始建立自己的 Java 分枝時，它不用 RMI 而改采自己的方式，你對此的看法如何？

Harold：微軟不用 RMI 是因為他們自己有一套 Windows 專屬的技術 DCOM，微軟也建立了 ActiveX 網(wǎng)頁內嵌動態(tài)內容的技術來和 Java 一別苗頭。但是不管 DCOM 或 ActiveX，都沒有在 Web 設計的市場上 有所斬獲，而且微軟也為了利益和某些目的而放棄了它們。事實上 RMI 和底層的 object serialization 機制實在慢得可怕，而且元兇就是於 Java 本身。我所接觸到的多數(shù)大型、非 applet 專案都是選用 CORBA，而非微軟的 DCOM 或 Java 的 RMI。

Wayner：你認為 NC 有沒有希望能以 applet 的方式下載軟體回來 執(zhí)行？在新版的 Java 2 中有沒有這個可能？

Harold：假如此事成真，也不會是在 PC 或任何電腦平臺上。電視游樂器或視訊接收盒（set-top box） 是更適合此方式的平臺。

Wayner：Sun 透過 Unicode 對於多文化多語言的支援是否已經(jīng)足夠？ 或只是聊備一格？

Harold：從 Java 1.1 開始，Java I/O 類別就已經(jīng)完全支援國際化。主要的問題在於程式員對此 尚不甚熟悉，因為他們老是用不支援國際化的程式語言（ 比方說 C 或 Pascal ）的思考方式強套在 Java I/O 上，其實兩者之間不相契合。一旦你了解在 Java 中不同國家的語言之間如何邏輯地切割功能，并知悉 他們的連接方式，使用起來就易如反掌，但假如你用別的程式語言想達到同樣的目的，你會發(fā)現(xiàn)復雜到 難以掌控。