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」，或者「作者直接 使用20年不变 Pascal 陈年老例，懒得花心思改写」。现在已经是 1999 年了，用户介面应该是 图形模式（ GUI）而非文字模式（ console ）。我们有必要在信息系的课程中向学生介绍现代化 GUI 程式设计方法。 现在我正在教研究生 Java 入门课程中，班上学生不超过10% 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 风味。
--------------------------------------------------------------------------------
湘公网安备43019002002060