人物专访: 畅销作家Harold《 Java I/O 》

核心提示：不要再以为 java 只能拿来设计网页上的动态图形，其实 Java 是一个功能完备的程式语言，人物专访: 畅销作家Harold《 Java I/O 》，而且是当今许多程式员的第一选择，因为 Java 语言具备清楚的架构、提供动态记忆体治理、 浑然天成地整合了 Web … 等优点，使用起来就易如反掌，但假如你用别的程式语

不要再以为 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 中不同国家的语言之间如何逻辑地切割功能，并知悉 他们的连接方式，使用起来就易如反掌，但假如你用别的程式语言想达到同样的目的，你会发现复杂到 难以掌控。