快捷搜索:

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

不要再以为 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 风味。

您可能还会对下面的文章感兴趣: