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

发布时间:2024-02-22 14:37:18

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

--------------------------------------------------------------------------------

上一篇 Garbage Collection 一直在执行? 还是需要时才启动?
下一篇 全面研读 EJB 2.0(2)

文章素材均来源于网络,如有侵权,请联系管理员删除。

标签: Java教程Java基础Java编程技巧面试题Java面试题