首頁
中文書目錄
原文書目錄
 站內快速搜尋
資源中心
Book Series
Special Interest













■好消息,歐萊禮書籍已重新鋪貨至各大書局及網路書店,歡迎讀者選購       ■歡迎各院校採用歐萊禮書籍,學校團購請洽校園服務團隊

[人物專訪]

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 風味。


| 首頁 | 聯絡我們 |
© 2009, O'Reilly Media, Inc. Taiwan Branch