[人物專訪]Elliotte Rusty Harold
本文譯自 O'Reilly 美國總公司網站上的文章
不要再以為 Java 只能拿來設計網頁上的動態圖形，其實 Java 是一個功能完備的程式語言，而且是當今許多程式員的第一選擇。因為 Java 語言具備清晰的架構、提供動態記憶體管理、 渾然天成地整合了 Web … 等優點，使得 Java 開發程式過程所需要的時間較許多其他開發工具少得多。 暢銷作家 Elliotte Rusty Harold 最近出版的 一本書《 Java I/O 》詳細地帶我們深入瞭解 Java I/O 的內部奧妙及其用法。我們特地邀請他接受我們幾分鐘的訪談， 針對 Sun 公司所規劃的 Java I/O 的方向。
Wayner：哪一類的 Java 程式員該對 Java I/O 相關議題感興趣？
Harold：所有的 Java 程式員都該對 Java I/O 感興趣。幾乎所有的程式多多少少都會牽涉到 I/O， 儘管其目的各有千秋。然而教科書上的 IO 範例常常只侷限在命令列參數（command line arguments）和 System.out.println()，卻忽略了真正的程式常需要讀寫檔案、讀寫網路、資料加密解密、從串列埠 （serial port）收送資料、和資料庫溝通 … 等。我們通常可以透過觀察程式員駕馭 I/O 的能力 來判斷他的專業程度，離 System.out.println() 越遠的程式員程度越專業。
Wayner：在許多人既定的印象中，Java 是用來寫網頁上 applet 的工具，但其實 Java 是一個功能完整的程式語言。你認為 Java 和 C++ 此二功能完整的程式語言在 I/O 方面的比較上如何 ?
Harold：毫無疑問地，Java 的 I/O 工具比 C/C++ 更加洗鍊、強大、且容易使用。 C/C++ 以及其他許多語言都假定讀寫的資料來自 1970 年代的陽春終端機之類的設備， 跟不上時代的腳步，現代的 C/C++ 程式員也就深為此所苦。Java 是第一個拋棄此包袱的主流程式語言。Java 的設計者 早就意識到檔案的讀寫、網路的連結、以及和串列埠的溝通相當重要，絕非資訊系一年級 學生的程式作業「讀入一個數目，輸出開根號的值」可以比擬的。
可惜的是，因為 Java I/O 所採行的結構相當不同於以往，使得許多程式員不知道它其實 很簡單卻也很強大。從我的學生們的反應、許多網路討論區、以及郵寄討論信件中，我發現 大多數的人一開始就問了不該問的問題。比方說，常有人問如何從 console 讀取一個數字。 其實，他們不應該一開始就和 console 打交道。
學生總是在問 Java 有沒有和 C 的 scanf() 類似的用法，我覺得這都要責怪教授沒有好好教。 你瞧瞧，市面上一堆介紹 Java 的書時常一開始就教讀者如何用 Java 寫出等同於 C 的 scanf() 和 printf() 等功能。 我覺得這個現象背後的因素可能為：「作者根本不瞭解 Java，特別是 Java I/O」，或者「作者直接 沿用二十年不變的 Pascal 陳年舊例，懶得花心思改寫」。現在已經是 1999 年了，使用者介面應該是 圖形模式（ GUI）而非文字模式（ console ）。我們有必要在資訊系的課程中向學生介紹現代化的 GUI 程式設計方式。 現在，我正在教研究生 Java 入門課程，班上的學生中不超過百分之十有 GUI 程式設計經驗。
當然，使用者介面是 GUI，不表示傳統的 I/O 方式不再重要。但是一旦你棄 console 不用， 你可以設計出更清楚的 I/O 介面，可輕易地支援檔案、網路 … 等，使用 Java 就有這樣的好處。
Wayner：至於那些 Web 的 applet 設計者來說，Java I/O 對他們有何影響呢？
Harold：Java 的安全機制嚴格地限制了網頁瀏覽器內的 applet 所能進行的 I/O 動作。 目前主要的瀏覽器尚未支援 Java 2 的安全模型，所以純粹只是「理論上可以， 實際上不行」。而且，大多數使用者不會因為希望網站設計人員較輕鬆就額外放寬 applet 的權限。 所以，一般 applet 使用到的 I/O 主要是和原伺服器之間建立網路連線、或使用 object serialization、 或 RMI。
Wayner：當微軟開始建立自己的 Java 分枝時，它不用 RMI 而改採自己的方式，你對此的看法如何？
Harold：微軟不用 RMI 是因為他們自己有一套 Windows 專屬的技術 DCOM，微軟也建立了 ActiveX 網頁內嵌動態內容的技術來和 Java 一別苗頭。但是不管 DCOM 或 ActiveX，都沒有在 Web 設計的市場上 有所斬獲，而且微軟也為了利益和某些目的而放棄了它們。事實上 RMI 和底層的 object serialization 機制實在慢得可怕，而且元兇就是於 Java 本身。我所接觸到的多數大型、非 applet 專案都是選用 CORBA，而非微軟的 DCOM 或 Java 的 RMI。
Wayner：你認為 NC 有沒有希望能以 applet 的方式下載軟體回來 執行？在新版的 Java 2 中有沒有這個可能？
Harold：如果此事成真，也不會是在 PC 或任何電腦平台上。電視遊樂器或視訊接收盒（set-top box） 是更適合此方式的平台。
Wayner：Sun 透過 Unicode 對於多文化多語言的支援是否已經足夠？ 或只是聊備一格？
Harold：從 Java 1.1 開始，Java I/O 類別就已經完全支援國際化。主要的問題在於程式員對此 尚不甚熟悉，因為他們老是用不支援國際化的程式語言（ 比方說 C 或 Pascal ）的思考方式強套在 Java I/O 上，其實兩者之間不相契合。一旦你瞭解在 Java 中不同國家的語言之間如何邏輯地切割功能，並知悉 他們的連接方式，使用起來就易如反掌，但如果你用別的程式語言想達到同樣的目的，你會發現複雜到 難以掌控。
Wayner：有沒有什麼 I/O 的功能 Sun 還需要加強或擴充的？
Harold：目前 Java 不支援位元組格式「由小到大（ little endian）」的資料，或其它次序的數值 （比方說 VAX 的浮點數）。但是，我在《 Java I/O 》一書設計了一些類別來告訴讀者如何讀寫特殊格式 的資料到資料流（ stream ）。這些類別也可以和標準資料流輕易地相互連接。
Wayner：你認為 Java 需要支援更多的編碼法嗎？
Harold：很明顯地，我們需要 Java 支援新的 Latin-0 字集來包含歐元符號。而且 Unicode 3.0 再幾個月就要出爐了，Java 也需要在幕後做一些對應的微調，這樣的動作不可影響到大多數現有的程式。 而且 IBM 宣稱 Sun 把 EBCDIC 轉換碼搞亂了，這一點也要改進（我個人認為這是 IBM 的錯，如果當初 他們有費點心思把 EBCDIC 標準化且整理好其文件，今天 EBCDIC 就不會這樣混亂了）。除了上面的問題 之外， Sun 其實在支援大多數的字集上做得不賴。
Wayner：許多人抱怨不同公司的 Java 環境上有不少差異，你有沒有發現什麼嚴重的問題肇因於此？有什麼地方我們應該注意的？
Harold： I/O 最大的問題在 java.io.File。雖然在 Java 2 已有改進，但仍顯露出它的 Unix 血統。 java.io.File 在 Unix 上運作得很好，在 Windows 上還可以，但在 Mac 上不忍卒睹， 因為 java.io.File 對 「檔案是什麼」和「檔名應該如何」做了許多簡化性的假設，偏偏這些加假設中 有許多是只相容於 Unix 環境，而不適用在非 Unix 平台。還有一些潛在的問題， 比方說： Sun 認定只要是不可在檔名中出現的兩個任意分隔字元就可以 分別當作檔名的分隔符號以及路徑的分隔符號，這樣的假設和 Mac 會產生衝突，對於 Mac 來說， 只有一個字元不能當作檔名的一部份。這使得 Java 移植到 Apple 電腦上時需要一些囉唆的步驟。
Wayner：最後一個問題：你認為 Sun 在讓 Java 跨平台這方面是不是做得不錯？或者你認為有某些地方太過於 Unix 化？
Harold：對於跨平台來說， AWT 是一大麻煩。我知道設計一個能跨越 Windows、Mac、以及 Motif 的 GUI 類別庫是相當困難的事，但 Sun 根本連試都沒試。不過在 Java 2 和 Swing 問世後， 情況已經好轉。雖然已經有改進了，但 Java 在這方面還是很蹩腳，因為它出自許多 Unix 程式員之手， 而且這些人對 Windows 和 Mac 所知不多。
Java 網路 API（比方說： java.net.Socket、 java.net.ServerSocket）也相當 Unix 化。 但其實 Windows 和 Mac 在網路的部分也很像 Unix，所以，在 Java 網路 API 上，倒不是很容易察覺 Unix 風味。 |