More Java Pitfalls中文版

Michael C. Daconta

著

Kevin T. Smith

Donald Avondolio

W. Clay Richardson

徐波译

赵科审校

人民邮电出版社

本书献给Edsger W. Dijkstra，这是对他永远的缅怀。他曾经说过：

“我的意思是，如果10年以后，当你偷偷地做一些虽然快速但不够严谨的事情时，你突然看到我仿佛在你的身后注视着你，令你扪心自责‘Dijkstra不会喜欢我这样干’。如果能够这样，我也算是没有虚度今生了。”

我们必须谦恭地表示不同意：Dijkstra的影响何止10年，即使10¹⁰年以后，他在天堂里也能欣慰地看到他的影响依然存在人间。相对于他在思想上达到的高度，这个评价绝非过分。

内容提要

本书通过分析和探究Java编程中的问题，总结出高效的解决方案，帮助Java程序员克服实际编程工作中的“陷阱”。

全书分为3个部分，50个Items。第一部分“客户层”（22个Items）涵盖了J2ME和J2SE，讨论了在开发网络和独立客户应用程序时可能遇到的陷阱。第二部分“Web层”（14个Items）探讨了运行于Web容器内部的组件的陷阱。第三部分“企业层”（14个Items）涉及到J2EE平台的一部分组件，或是在企业Java Bean（EJB）容器内部的执行。

本书适合有一定经验的Java程序员阅读，也可作为工作中解决实际问题的参考书。

前言

“有时候，我们会发现一些令人不快的真相。每当此时，我们便陷于两难的境地：从科学的角度讲，隐瞒它们是不诚实的表现，因此我们必须公布它们。但是，一旦公布了它们，我们等于是朝自己脸上打了一巴掌。”

Edsger W. Dijkstra, “我们如何公布可能造成伤害的真相？”

编程要达到优秀的境界是极为困难的。对于程序员新手而言，他们需要精通的软件工程知识体系（www.swebok.org）的规模不断扩展，内容不断变化，他们的前行之路显得格外艰辛。本书的作者发觉，不论是对程序员的工作效率还是对软件的可靠性而言，丰富的经验和深入的理解是两个关键的因素。至少，经验丰富的程序员不会在黑暗中绊跤。他们熟知那里的地形，他们知道那里的高低起伏，因而可以避开那些危险区域。本书向读者展示了我们的经验，对50个分立的话题提供了指导意见，帮助你避开那些危险地带。

什么是陷阱

在Java Pitfalls（Wiley，2000）[1]一书中，我们首次给出了陷阱（pitfall）的正式定义：

“陷阱，是指那些能够正常编译，但在执行时却产生事与愿违的，有时甚至是灾难性后果的程序代码。”

这个相对简洁的定义覆盖了被我们认为是“基本”的陷阱。对于陷阱的定义还有许多种说法。一个更为广泛的定义是：任何可能导致程序员把大量的时间浪费在开发工具的使用上而不是最终软件的进展上的语言特性、API或系统，都可以称为陷阱。

产生陷阱的原因大致可以分成两种类型：平台设计者的失误和经验欠丰的程序员的过失。这样分类不是为了追究责任，而是从构建陷阱分类学的角度来确定陷阱的根源。我们在图1.1中展示了陷阱的分类，目的就是更好地理解这些让我们陷入困境的东西。

图1.1 陷阱分类学

和系统设计者相关的陷阱类型有下面几种：

不直观的应用程序编程接口（API）。Java平台具有数千个类和数万个方法。仅这个平台的规模就已经是一个复杂的陷阱。有些类设计得非常出色，如Servlet、IO流（排除效率因素）和Collection（集合）。遗憾的是，许多API设计得很不直观，其原因如下：

l 错误的抽象层。许多API是构筑于其他软件（如操作系统或本地代码）的层面之上的，目的是为了对功能进行简化或聚合。在设计API时，设计人员必须在简单性和控制粒度之间进行权衡。因此，在设置抽象层时，设计人员必须根据具体的环境和目标用户制定适当的不失平衡的方案。如果抽象层次太高（如URLConnection, Item17），用户可能会因为对各种映射关系的控制能力太弱而感到失望。如果抽象层次太低，用户可能会在那些最常见的操作中浪费太多的时间，从而导致效率低下。

l 焦点分离的不足。当一个API试图实现太多的功能时，它常常会混杂许多隐晦的含义，从而以一种不理想的风格处理它的多个焦点。这方面的一个例子是JAXR API，它试图将不同的信息模型UDDI和ebXML组合在一起（Item47）。

l 其他缺陷。太多的方法调用序列和依赖关系有可能导致不正确的操作顺序。低劣的命名和弱类型参数（object而不是某种具体的类型）有可能将程序员逼上绝路。

语言的复杂性。和它的前辈语言相比，Java语言有了许多改进，但它仍然深陷于各种折衷和特性的漩涡之中。它最干净的语言特性是它严格的面向对象性、自动内存管理和接口。但它的有些语言特性（如线程和同步、基本类型和对象之间的对立以及异常的有效使用等）过于复杂了。

平台领域的实现方式欠佳。这方面最常被人们所提及的就是效率问题。这方面的一个典型例子是：由于效率的原因，语言设计者在NIO程序包中重新编写了输入/输出工具。除了效率之外，还有一些API破坏了Java语言“一次编写、到处运行（WORA）”的保证，如File.renameTo()方法（Item 20）和Runtime.exec()方法（Item 1）。还有一些API并不完整，但程序员却以为它提供了完整的功能。这些问题是可以修正的，它们通常在Java Development Kit（JDK）的新版本中解决。

和程序员有关的陷阱类型有下面几种：

知识的匮乏。经验可以提升程序员的知识深度。学习一个系统的底层概念、相互作用以及细微之处需要时间。这常常表现在当存在一个更好的替代方案时，偏偏选择了一个不理想的实现方案（如Applet和Web Start，Item 26）、对一个API内部工作过程的理解有误（如Servlet实例变量的结果，Item 31）以及当实现方案无法达到你预期的行为时感到震惊（在图1.1中用阻抗不匹配来表示）。这种阻抗不匹配可能发生在多重并发结果集中（Item 41）。

偏见。如果没有多年的经验，程序员可能会过于倚重以前的经验，这可能导致他偏向于某个特定的方向。这方面的例子是不利用那些能够用于自动开发过程的工具如Ant（Item 11）和JUnit（Item 12）。另外一个例子是坚持使用原先的API，对用于集合（Item 21）和正则表达式（Item 30）的新API视而不见。最后，还有一种偏见就是把原先的习惯带到一个新的编程环境中，如J2ME编程（Item 22）。

无效的假设。程序员可能会根据无效的假设作出不正确的决定，例如，他可能会以为最直接的解决方案就是最好的解决方案。这种情况常常在使用JSP（Item24）和J2EE（Item22）设计大型系统时出现。

陷阱可能会令程序员产生强烈的挫折感。我们首先经历了这些挫折。我们的目标就是帮助读者避免一些我们曾经痛苦不堪的遭遇。既然我们现在已经知道了什么是陷阱，接下来请看一下我们分析陷阱的方法。

分析陷阱

每个Item由3个不同的部分组成：

症状或问题。显示陷阱所造成的后果。我们用一个名叫“BadXXX.java”的程序来说明这个问题，其中“XXX”表示问题所存在的陷阱类型。

问题的根源。这是揭示陷阱最重要的一个部分。在此，我们深入底层，解释了可能导致程序员绊跤的详细内部工作过程、无效的假设或者API缺陷。通常这种解释将使用一张图来强化读者的认识。

解决方案（solution）或解决办法（workaround）。最后一部分是展示问题的解决方法。这是用一个名叫“GoodXXX.java”程序实现的，它是“BadXXX.java”的对应程序。这个问题解决程序通常还将给出运行结果，或者是一张表，或者是一张图，证明问题确实已经解决。

这种分析陷阱的方法被证明是一种有效的方法，它很好地展示了这些编程暗礁的所在。

本书与Java Pitfalls有何不同

本书继承了Java Pitfalls的许多优秀特性，并在三个方面作了改进：

更广的覆盖。Java Pitfalls把注意力集中于lang、util、io和GUI 程序包中，本书则覆盖了J2ME、J2SE和J2EE平台。

新的特性。本书涵盖了大部分新特性，如正则表达式、NIO、断言、JAXR、JAXM、JAX-RPC等许多新特性。

更佳的覆盖。作者更为准确和完整地遵循了“分析陷阱”的模型，对陷阱的描述更为周全、分析更为详尽。

总之，作者努力使本书在各个方面都超越Java Pitfalls。我们真诚地希望我们能够实现我们的目标，并鼓励广大读者的把意见反馈给我们。

本书的组织形式

和Java Pitfalls一样，本书也有50个Item。但和Java Pitfalls不同，本书只划分为三个部分，分别对应于三层体系结构。

第一部分：客户层（The Client Tier）。这部分涵盖了J2ME和J2SE，探索了在开发网络和独立客户应用程序时可能遇到的陷阱。这部分讨论的话题包括偏好（Preference）、应用程序部署、日志、IO效率等。这部分共包括22个陷阱。

第二部分：Web层（The Web Tier）。这部分研究运行于Web容器内部的组件的陷阱，如Servlet和JSP页面。这些应用程序产生动态Web页面或者与Applet、JNLP或独立的客户进行交互。这部分涵盖的话题有JSP设计、缓存技术（Caching）、Servlet过滤器（Servlet Filter）、数据库连接（Database Connection）、表单验证（Form Validation）等。这部分共包括14个陷阱。

第三部分：企业层（The Enterprise Tier）。这部分我们所观察的组件是J2EE平台的一部分，或者是在企业Java Bean（EJB）容器的内部执行，如会话Bean、实体Bean和消息驱动Bean。这些组件与其他企业系统（Enterprise System）、遗留系统（Legacy System）和Web层进行交互，或者直接与客户进行交互。由于Web服务在企业层中扮演了关键角色，所以有些与Web 服务API（JAXR和JAX-RPC）相关的陷阱也在这一部分进行描述。这部分的其他话题有J2EE设计错误、会话Bean、Java数据对象（JDO，Java Data Object）、安全（Security）、事务（Transaction）等。这部分共包括14个陷阱。

如何使用本书

你可以按照三种方式使用本书：作为某些特定问题的参考手册、作为问题所提示的话题的教材、作为你所在组织的技术指导程序的着手点。让我们分别详细讨论。

作为参考手册。你可以根据目录，研究你所面临的问题的具体解决方案。绝大多数读者按照这种方式使用本书。有些读者反馈他们把第1本书（Java Pitfalls）作为技术图书馆的公共资源使用。

作为教材。你从头到尾阅读本书，学习每个陷阱的根源。用这种方式阅读本书的另一种方法是浏览目录或正文，然后阅读你感兴趣的陷阱。最后，你可以在一些非正式的内部练兵活动或技术交流会议上把每个陷阱作为小型教材使用。

作为指导程序的一部分。你可以把本书作为你所在组织的技术指导程序的起点。本书是在平等指导的原则下编写的。“指导者”的词典定义是“聪明且值得信赖的顾问”。这常常使人们误以为指导者必须年龄更长、经验更丰富。我反对这个定义，因为符合这个定义的优秀指导者太少了。从本质上说，指导是探索真理的某个方面。因此，成为一名指导者的关键素质是你必须在一个领域有深入的理解，并且愿意让别人共享你的知识。任何人都可以参与这个过程，我鼓励你加入到平等指导的行列中。大家一起工作，我相信我们能够解决软件质量的危机。

本书的配套网站有哪些内容

本书的配套网站（http://www.wiley.com/legacy/compbooks/daconta/ mjp/）包含4个关键内容：

l 源代码。本书所有程序清单的源代码以压缩文档的形式提供。

l 勘误表。读者或作者发现的任何错误将列入到对应的修正文本中。

l 样章。尚未购买本书，但对它的风格和内容感兴趣的人们可以索取本书的样章、目录表和索引。

l 联系地址。作者的邮件地址以及一些FAQ的答案。

欢迎评论

本书是由程序员为程序员而编写（Programmer for Programmer）的。我们欢迎整个计算机社区的所有评论、建议和问题。读者的反馈使我们的写作更有价值，而且有助于提高我们的工作质量。我感谢所有花时间与我们接触，报告错误、提出建设性意见或表达赞赏的人们。

我的邮件地址是：mike@daconta.net。你也可以通过下面的通信地址与我联系：

Michael C. Daconta

C/o Robert Elliott

Wiley Publishing, Inc.

111 River Street

Hoboken, NJ 07030

致真诚的祝福！

Michael Daconta

一亚利桑那州Sierra Vista

注意：

对代码的说明：在许多代码清单中，你可以发现某些行的最右端有一个符号，表示一行的空间无法写下整个代码行的所有字符，此处表示转行，下一行的内容属于上一行的连续。

第一部分客户层

“现在，如果我们把编程语言主要当作是一种把问题输入到机器的手段，那么编程语言的质量就取决于它‘充分利用机器’的程度。”

Edsger W. Dijkstra，
“设计与机器无关的编程语言”

使用Java开发以客户端为主的应用程序曾经出现过一些引人注目的失败项目。Corel用Java开发了一个办公套件，但在发布了一个早期的beta版之后就放弃了该项目。Netscape曾尝试开发一个纯Java版本的Web浏览器（称为“Javagator”），但这个工程还没有发布任何代码便宣告取消。虽然这些事情发生在客户端Java的早期阶段，大概是在1997～1998年时期，但对于客户端Java而言，无疑已经作出了一个令人沮丧的结论。因此，人们对Java的兴趣逐渐转向了服务器端。但是，即使是在服务器端Java的阴影之下，客户端Java仍然在慢慢地改进。随着每个新版本的发布，Java平台出现了更丰富的用户接口、更快的虚拟机、粒度更精细的安全模型以及更方便的网络部署。因此，借用Microsoft常用的一种说法，客户端Java一直在正视着它的缺点，并随着每个新版本的发布逐渐改进。今天，我们已经看到了许多用Java开发的引人注目并且非常成功的商业应用程序，如ThinkFree Office、Borland的Jbuilder、TIBCO的Turbo XML编辑器和TogetherSoft的Together Control Center UML建模工具。因此，用Java开发丰富的客户端应用程序是完全可能的。本书的第一部分就是帮助你在这方面有所建树。

本书的第一部分探讨了客户端开发的3个通用领域中存在的陷阱：效率、不直观的应用程序编程接口（API）和更好的替代方案。这里给出了每个领域的陷阱的一些要点。

效率长期以来一直是客户端Java为人诟病之处。我们的前一本书，Java Pitfalls： Time-Saviing Solutions and Workarounds to Improve Programs，讲述了许多有关效率的陷阱。许多其他书籍以及许多网站的目标都是致力于提高Java的效率。这部分有两个和效率有关的陷阱：

l NIO的效率和陷阱（Item 2）。这个Item研究了新IO程序包在IO效率上的改进，它研究了文件通道（File Channel）、ByteBuffer和非阻塞性服务器IO（non-blocking server IO）。

l J2ME的效率和陷阱（Item 22）。在这个Item里，我把一个Swing应用程序移植到J2ME平台，并展示了其中的API陷阱以及超过20个的针对这些小型设备应用程序的优化措施。

不直观的API可能会让你浪费数个小时仍然一无所获，本书第一部分的大部分陷阱属于这一类。我们将对API进行仔细分析，研究软件的内部工作过程，并提供这些问题的解决方法。解决方法有时涉及到正确的操作序列，不同的类的使用，或者放弃标准API，寻求开放源代码的替代方案。

l 当Runtime.exec()运行出错时（Item 1）。这个陷阱是一个典型的用户期望值和一个功能不完备的API之间不匹配的例子。

l 在java.util.logging中避免粒度陷阱（Item 5）。新的java.util.logging API存在一些隐蔽的复杂性和相互关系，它们将会影响报告粒度的层次。你必须理解logger和handler之间的关系，以便有效地使用这个API。

l 查找DOM的错误方法（Item 8）。在JDK 1.4中，Java平台使用javax.xml程序包提供了对XML的本地支持。不幸的是，文档对象模型（DOM， Document Object Model）最直观的表示形式却不是正确的表示形式。这个Item深入地探索了其中的缘由。

l 保存DOM的困境（Item 9）。JAXP引入了一些标准的方法创建和操纵XML DOM树，但它在对它们进行持久化方面的能力较弱——这迫使开发人员使用依赖编译器的方法。这个Item讨论了这方面的挑战。

l 执行的失败（Item 13）。Java Archive或JAR是Java组件二进制发布的主要形式。遗憾的是，在这些文件的工作原理以及执行方式方面存在很大的混淆。这个Item探索了这些问题并对使用JAR文件的最佳方式提供了解释。

l 当POST到一个URL无法如愿时（Item 17）。java.net API中的URL和URLConnection类是在一个相当高的抽象层次设计的，它们很容易引起混淆。这个Item展示了一些使用API的不正确方法，揭示了这些缺陷背后的原因，并提供了这个问题的一个解决方案以及一个开放源代码替代方案。

随着平台的逐渐老化以及不得不沿用欠佳的方案以维持向后兼容，存在标准之外的更好替代方案这个问题可以说是日渐凸现。除了平台中新的API之外，开放源代码替代方案在许多服务领域都证明了自己是最佳方案。

l 我宁愿不使用属性（Item 3）。这个Item展示了Properties类的一些弱点，并说明了为什么说java.util.prefs程序包提供了一个更好的解决方案。

l 当信息隐藏得太多时（Item 4）。对抽象事物而言，开发人员常常遇到的一个问题是它可能向开发人员隐藏一些重要的信息。异常就是一个典型的例子。这个Item展示了在新的JDK 1.4中，链式异常工具是如何解决这个问题的。

l 当标准API的实现发生冲突时（Item 6）：在XML成为JDK 1.4的一部分之后，随之立即产生了一个问题，就是XML标准和JDK版本之间的不同步。本节将介绍JDK 1.4是如何对这些已经认可的标准的更新提供支持的。

l 断言绝非多余（Item 7）。从新特性的引入到大部分程序员采纳这个特性通常有一个时间上的延迟。对于像断言这种关键的可靠性方面的改进，这种采纳延迟是一个严重的问题。这个Item将指导你如何使用这个重要的工具。

l Apache Ant和生命周期管理（Lifecycle Management）（Item 11）。虽然第一部分的绝大多数陷阱出现在语言和API层次，但这个陷阱的视野更为广阔，它寻找一种软件生命周期管理的更好替代方案。对于团队开发而言，忽视类似Ant这样的创建工具可以说是一个严重的陷阱。

l JUnit：单元测试使事物变得简单（Item 12）。和Ant创建工具一样，JUnit也是一个非常重要的工具。通过单元测试，它可以确保代码的质量。这个Item展示了如何有效地使用JUnit，并解释了为什么忽略它是一件糟糕的事。

l 使用Iteration替代Enumeration（Item 21）。Collection API被证明是高效的且很受欢迎。这个Item揭示了Enumeration的实现所存在的一个弱点，并对其内部细节进行了研究，找出了问题的根源，展示了Iteration是如何解决这个问题的。

本书的第一部分包括22个陷阱，覆盖了许多需要避免的客户端陷阱。使用这些解决方法和技巧使你能够创建健壮的客户端应用程序，“更好地利用机器”。这部分剩余的陷阱还有：

l 鼠标按钮的可移植性（Item 10）。Java是开发跨平台应用程序的优秀选择。不幸的是，并不是所有的平台都是相同的，尤其是涉及最常见的输入设备——鼠标时。这个Item展示了在不同的输入设备之间进行工作所面临的挑战。

l 你收集了什么（Item 14）。在处理Collection API时，抽象过度这个问题变得格外尖锐。这个Item展示了一些集合的元素类型未知的例子，并讨论了解决这个问题的最新策略。

l 避免Singleton陷阱（Item 15）。Singleton（单件）模式是一种广泛使用的Java开发模式。不幸的是，在如何使用Singleton方面，开发人员常常会出现许多错误。这个Item说明了这些错误，并建议了一些解决办法。

l 当setSize()无法如愿时（Item 16）。开发人员（尤其是那些新手）常常会使用一些方法，但他们对与此相关联的API却没有一个全面的理解。这方面一个很好的例子就是setSize()方法的使用，它可能会导致意想不到的结果。这个Item不仅研究了setSize()方法的错误用法，而且讨论了布局管理器（Layout Manager）的概念。

l 有效的字符串标记化（Item 18）。StringTokenizer类的操作常常被人误解。用多字符作为定界符的字符串有时会出现一些有趣的问题。这个Item对这些问题进行了研究，并解释了如何避免这些问题。

l JLayered Pane陷阱（Item 19）。这个Item研究了与使用Swing的Layered Pane有关的问题，尤其是在它上面使用布局管理器有关的那些问题。

l 当File.renameTo()运行出错时（Item 20）。在Java中，文件的相互作用可能导致意想不到的结果，尤其是在跨文件系统或跨平台的情况下。这个Item探讨了这些意想不到的结果，并提供了这些问题的解决方案。

Item 1：当Runtime.exec()运行出错时[2]

java.lang.Runtime类有一个静态方法称为getRuntime()，它用于获取当前的Java运行时环境。如果你想获得一个Runtime对象的引用，这是惟一的方法。有了这个引用之后，你可以调用Runtime类的exec()方法来运行外部程序。启动浏览器显示某些类型的HTML形式的帮助页面往往就需要这样做。exec()方法共有4个重载版本，它们的原型如下：

l public Process exec(String command)；

l public Process exec(String [] cmdArray)；

l public Process exec(String command， String [] envp)；

l public Process exec(String [] cmdArray， String [] envp)；

所有这些方法背后的基本思路是：把一个命令（可能还有一组参数）传递给一个因操作系统而异的函数调用，将一个Process类的引用返回给Java虚拟机（VM），从而创建一个因操作系统而异的进程（一个运行中的程序）。Process类是一个抽象类，这是因为每个操作系统都有一个特定的Process类的子类。这些方法有3种可能的输入参数：单个String参数，它同时表示需要执行的程序和该程序的所有参数；一个String数组，它将程序及其参数区分开来表示；一个环境变量数组，环境变量参数根据name=value这样的格式进行传递。注意，如果你使用的exec()方法使用的是既表示程序又表示其参数的单个String参数，程序对这个String参数进行解析时使用空白作为分隔符，这是通过StringTokenizer类实现的。

现在常见的对一个API的首次测试就是用它最显而易见的方法进行编码。例如，为了执行一个JVM外部的进程，我们使用exec()方法。为了观察外部进程的返回值，我们使用Process类的exitValue()方法。在我们的第1个例子中，我们试图执行Java编译程序（javac.exe）。程序清单1.1就负责执行这项任务。

程序清单 1.1 BadExecJavac.java

运行BadExecJavac程序产生下面的输出：

这个程序无法运行，因为如果外部进程尚未完成，exitValue()方法将抛出一个IllegalThreadStateException异常，文档中就是这样描述的。但这确实显得奇怪，人们忍不住要问：为什么不让这个方法继续等待，直到它可以给我们一个有效的答案呢？再次仔细审视Process类所提供的方法之后，我们可以发现waitFor()方法就是用于执行这项任务的。事实上，waitFor()方法返回一个退出值，这意味着你不会同时使用这两个方法。你要么选择waitFor()，要么选择exitValue()。你惟一可能使用exitValue()方法替代waitFor()方法的原因是你不希望程序因为等待一个可能永远也不会完成的外部进程而阻塞。从个人的角度讲，我倾向于让exitValue()方法具有一个名为waitFor的布尔型参数，用于确定当前线程是否应该进行等待。我认为使用一个布尔型参数的方案更好一些，因为exitValue()这个名字用于这个方法更为恰当一些。我们没有必要让两个不同的方法在不同的条件下执行相同的功能。这种简单的“条件”区分通过使用一个输入参数就完全可以达到目的。

所以，与Runtime.exec()方法相关的第1个陷阱就是要小心IllegalThreadStateException异常，你可以捕捉这个异常，也可以等待进程完成。现在，让我们对上面这个程序进行修正，选择等待进程完成。在程序清单1.2中，程序仍然尝试执行javac.exe程序，并进行等待，直到这个外部进程完成。

程序清单 1.2 BadExecJavac2.java

遗憾的是，运行BadExecJavac2程序不会产生任何输出。这个程序将会挂起，永远不会完成。为什么javac进程永远不会完成呢？javadoc文档提供了答案：“由于有些本地平台为标准输入和输出流所提供的缓冲区大小有限，如果不能及时写入子进程的输入流或者读取子进程的输出流，可能导致子进程阻塞，甚至陷入死锁（deadlock）”。那么，这是否是程序员没有“RTFM[3]”而导致的一种情况呢？从某种角度讲，确实如此。在这个例子中，阅读手册将使你进退两难。手册告诉你需要对外部进程的流进行处理，但它并没有告诉你该怎么做。除了RTFM之外，当你在新闻组研究这个API常见的问题和错误时，很可能忽视一个实际上很重要的因素。Runtime.exec()和Process类所提供的API看上去极为简单，但其实暗藏玄机，因为这些API的简单（或者说是显见）应用很容易发生错误。

在此，API设计者的教训是简单的API应该用于简单的操作。那些趋于复杂或者具有特定平台依赖性的操作应该准确地反映它们的概念域。对事物的抽象做得过头其实也不好，正所谓过犹不及嘛。一个更好的用于处理这些操作的API例子是JConfig程序库（http：//www.tolstoy.com/samizdat/jconfig.html）。因此，现在让我们按照文档的要求对javac进程的输出进行处理。当你不用任何参数运行javac程序时，它将展示一组用法说明，描述程序的用法以及所有可用的程序选项的含义。如果你知道了这些信息将送往stderr流，就很容易编写一个程序在等待进程退出之前耗尽这个流。程序清单1.3就是执行这项工作的。虽然这种方法可以达到目的，但这并不是一种优秀的通用解决方案。这也是程序清单1.3为什么被命名为MediocreExecJavac的原因。它只是个一般（mediocre）的解决方案，一个更好的解决方案是既清空标准错误流又清空标准输出流，最好的解决方案则是同步清空这两个流（这个留待以后说明）。

程序清单 1.3 MediocreExecJavac.java

运行MediocreExecJavac程序将得到下面的输出：

如上所示，MediocreExecJavac程序可以运行，并且产生退出值2。在正常情况下，退出值0意味着成功，非0值意味着错误。遗憾的是，这些退出值的含义因操作系统而异。在Win32中，值为2的错误代码表示“文件未找到”。这是合乎道理的，因为javac期望我们在程序名的后面输入需要编译的源代码文件。所以，使用Runtime.exec()方法应该避免的第2个陷阱是：如果你所运行的外部程序将得到输出或者期待输入，你应该确保在你的进程中对输入和输出流进行处理。

让我们回到Windows系统，许多程序员新手在试图使用Runtime.exec()方法处理非可执行命令如dir和copy时会感到为难。因此，我们把exec()方法的参数从“javac”换成“dir”，如下所示：

Process proc = rt.exec(“dir”)；

我们创建一个名叫BadExecWinDir的程序，除了上面这行代码外，它和MediocreExecjavac相同。运行这个程序产生下面的输出：

前面我已经说过，错误值2表示文件未找到，也就是说名为dir.exe的可执行文件未能找到。这是因为dir命令是Windows命令解释器的一部分，它并不是一个单独的可执行程序。为了运行Windows命令解释器，根据你所使用的Windows操作系统，你或者执行command.com，或者执行cmd.exe。程序清单1.4运行Windows命令解释器的一份拷贝，然后执行用户提供的命令（如dir）。

程序清单1.4 GoodWindowsExec.java

用dir命令作为参数运行GoodWindowsExec程序产生下列输出：

用任何关联的文档类型运行GoodWindowsExec程序将启动与该文档类型相关联的应用程序。例如，为了启动Microsoft Word显示一个Word文档（扩展名为.doc），你可以使用下面的输入：

>java org.javapitfalls.item1.GoodWindowsExec “yourdoc.doc”

注意GoodWindowsExec使用os.name系统属性判断你正在运行的Windows操作系统的类型，并据此使用正确的命令解释器。执行命令解释程序之后，我们使用StreamGobbler类处理标准错误和标准输入流。StreamGobbler类在一个单独的线程里清空任何作为参数传递给它的流。当这个类把刚刚读取的输入行打印到控制台（console）时，它使用一个简单的String类型表示它正在清空的是哪个流。所以，我们需要避免的第3个陷阱是弄清你正在执行的是一个独立的可执行程序还是一个经过解释的命令。在本节的最后，我将展示一个简单的命令行工具，它可以帮助你判断你所运行的是哪种类型的程序。

值得注意的是在Process类中，用于取得进程输出流的方法称为getInputStream()。我们这里提到输出流，是因为站在Java程序的角度而不是外部进程的角度。所以，外部进程的输出就是Java程序的输入。从这个角度来看，外部进程中的输入流在Java程序中便成了输出流。

和Runtime.exec()方法有关的最后一个陷阱就是不要以为exec()能够接受命令行（或shell）所能接受的所有String参数。这个陷阱并不严重，而且并不是所有的平台都存在这个问题。这个陷阱的最主要诱因是用户在使用exec()方法时试图让它像命令行一样接受单个String参数。这个混淆很可能是由于exec()方法的参数名是command所致。程序员可能会错误地把command参数和任何你可以在命令行中输入的东西联系起来，而并没有意识到command参数应该是一个程序名和该程序的参数。例如，用户试图执行一个程序，并在exec()方法中对程序的输出进行重定向。程序清单1.5试图执行这项任务。

程序清单1.5 BadWinRedirect.java

运行BadWinRedirect程序产生下列输出：

BadWinRedirect程序试图把一个简单的Java版echo程序的输出重定向到文件test.txt。然而，当我们对输出结果进行检查，观察test.txt文件是否已被创建时，结果发现它并不存在。jecho程序简单地接受它的命令行参数并把它们写入到标准输出流。jecho程序的源代码可以在Web站点找到。用户以为你可以像在一个DOS命令行中那样把标准输出重定向到一个文件。遗憾的是，此时你不能用这种方法对输出流进行重定向。在这里，你不要以为exec()方法的行为和shell解释器是相同的，事实上它们是不一样的。exec()方法执行一个可执行程序（程序或脚本）。如果你希望对流进行处理，对它进行重定向或者通过管道（pipe）输送到其他程序，你必须使用java.io 程序包按照一定的操作顺序执行这项任务。程序清单1.6正确地把jecho进程的标准输出流重定向到一个文件。

程序清单1.6 GoodWinRedirect.java

运行GoodWinRedirect程序产生如下输出：

运行GoodWinRedirect程序之后，我们发现test.txt文件已经存在。这个陷阱的解决方案是通过把外部进程标准输出流的处理从Runtime.exec()方法中分离出来，简单地对重定向进行处理。我们创建一个独立的OutputStream流，读入文件名作为重定向的目标，打开文件，将我们从那个衍生的外部进程的标准输出所获得的输出写入到这个文件中。在程序清单1.7中，这个任务是通过为我们的StreamGobbler类添加一个新的构造方法实现的。这个新的构造方法接受3个参数：(1)需要清空的输入流，(2)一个String类型的参数，用于表示我们正在清空的流，(3)输入重定向所至的输出流。这个新版本的StreamGobbler类并不会破坏以前使用它的代码，因为我们并没有对原有的公用API进行修改（只是对它进行扩展而已）。JavaWorld文章的一位读者George Neervoort注意到，GoodWinRedirect程序可以作出的一个重要改进就是确保流已经完成了从进程读取的输入。这是必要的，因为进程有可能在线程完成之前就结束。下面是他对这个问题的解决方案（感谢George）

既然Runtime.exec()方法的参数取决于操作系统，我们应该使用的正确命令也因操作系统而异。所以，在最终确定Runtime.exec()方法的参数之前，能够在编写代码前快速测试一下参数是很有价值的。程序清单1.7是一个简单的命令行工具，允许你完成这项工作。

程序清单1.7 TestExec.java

运行TestExec程序，启动Netscape浏览器并载入Java帮助文档，将产生下列输出：

如上所示，我们的第1次测试失败，错误代码为193。在Win32中，值为193的错误代码表示“不是一个有效的Win32应用程序”。它告诉我们无法找到那个关联的应用程序（如Netscape），没有这个关联的应用程序，进程无法运行一个HTML文件。因此，我们可以再次进行测试，这次给出了Netscape的完整路径（或者我们可以把Netscape添加到我们的PATH环境变量中）。这次，运行TestExec程序产生如下输出：

行了！Netscape浏览器启动，并且载入了Java帮助文档。

一个有用的练习是对TestExec程序进行修改，把标准输入和标准错误重定向到一个文件。当你在Windows95或Windows98上执行javac编译程序时，这种方法可以解决错误信息溢出有限的命令行缓冲区这个问题。为了把标准输出和标准错误捕捉到一个文件中，下面列出了一些关键的代码行：

TestExec程序的另一个可供改进之处是设置一个命令行开关，允许从标准输入接受输入。这个输入随后使用Process.getOutputStream()方法传递给那个衍生的外部程序。本节探讨了和使用Runtime.exec()方法有关的几个问题，并提供了一些解决方案，协助你执行外部应用程序。

Item 2：NIO的效率和陷阱

NIO 程序包在输入/输出（IO）的效率方面迈出了一大步，并且增加了许多新特性。但是，这些提高并非完全没有代价，它不仅进一步增加了IO的复杂性，而且隐藏了一些潜在的陷阱。在这个Item中，我们将研究这个新程序包的一些优点和缺点。在研究具体的特性之前，让我们先站在较高的视点上，对NIO 程序包以及它的特性作一番浏览。在NIO 程序包中，共有4个主要的抽象概念。

通道（Channel）。通道表示与能够执行IO操作的实体之间的一个连接，这类实体有文件和套接字（socket）等。通道是根据它所连接的实体的类型分类的，如FileChannel或SocketChannel。为了提高IO操作的速度，通道和缓冲区联合工作，进行读取或写入。有些通道以接口的形式出现，分别扮演不同的角色，如GatheringByteChannel或ScatteringByteChannel，它们可以从多种序列的缓冲区进行读取或写入。最后，你可以通过FileInputStream、FileOutputStream、ServerSocket、Socket和RandomAccessFile类获取一个通道。遗憾的是，在已经十分拥挤的IO领域（stream、pipe、reader、writer）里再添加这些新概念，对绝大多数程序员而言是极容易引起混淆的。同时，这些概念相互之间存在重叠，它们的API之间也会互相影响。总之，为数众多的IO类所导致的复杂性以及它们在功能上的重叠，是这个领域最大的一个陷阱。

缓冲区（Buffer）。缓冲区是一种泛型数据容器，它可以对单种数据类型的随机访问进行操纵。它们与Charset或Channel类集成在一起。每个缓冲区包括一个标志（mark）、位置（position）、限制（limit）和容量（capacity）值（以及用于操纵的对应方法）。其中位置可以设置为缓冲区中的任何地点。缓冲区根据模式确定它的工作方式（读取或写入），如果我们需要修改缓冲区的工作方式，必须对这个模式进行“翻转”。

字符集（Charset）。字符集就是字节和16位的Unicode字符之间的名称映射。这些字符集的名字在IANA字符集注册表（http：//www.iana.org/assignments/character-sets）中列出。

选择器（Selector）。Selector类用于将一个SelectableChannel对象多路化（multiplex）。SelectableChannel只有一个子类，称为AbstractSelectableChannel。AbstractSelectableChannel类有5个直接的子类：DatagramChannel、Pipe.SinkChannel、Pipe.SourceChannel、ServerSocketChannel和SocketChannel。在网络通信中，多路器（multiplexer）就是一种能够在一条线路上发送几个信号的设备。Selector类管理一组包括一个或多个“可选择”的通道，并提供单个访问点从这些通道中的任何一个进行输入。

表2.1列出了NIO 程序包中所有关键的类和接口。

表2.1 关键的NIO类和接口

程序包	类/接口	描述
java.nio	Buffer	用于临时数据存储和操纵的随机访问数据容器
java.nio	ByteBuffer， CharBuffer， DoubleBuffer， FloatBuffer， IntBuffer， LongBuffer， ShortBuffer	存储特定数据类型的缓冲区，它的名字提示了它所存储的数据类型
java.nio	MappedByteBuffer	ByteBuffer的一种，它的内容是一个文件的内存映射区域。它是通过FileChannel.map()方法创建的
java.nio	ByteOrder	一种类型安全的字节顺序枚举：LITTLE_ENDIAN或BIG_ENDIAN
java.nio.channels	Channel	这个接口表示一个打开或关闭的与IO设备的连接
java.nio.channels	Channels	这个类包含了一些与通道操作有关的实用方法
java.nio.channels	FileChannel， Pipe， DatagramChannel， SocketChannel， ServerSocketChannel ， SelectableChannel	表示具体的通道类型，分别与特定的设备一起工作，如文件和套接字。DatagramChannel是一种与DatagramSockets（使用用户数据报协议即UDP）一起工作的通道。管道用于执行线程之间的通信
java.nio.channels	FileLock	这个类表示一个文件某个区域的一个锁。这种类型的对象可以通过FileChannel类的lock()或tryLock()方法创建
java.nio.channels	Selector， SelectionKey	如前所述，Selector是一个类，它用于将一个或多个SelectableChannels对象多路化。SelectionKey用于在监听（或选择）一个特定的SelectableChannel对象时指定一些具体的操作
java.nio.charset	Charset	这是个抽象类，它提供了16位的Unicode字节和字符序列之间的映射。标准字符集是US-ASCII（7位的ASCII）、ISO－8859－1（ISO　Latin）、UTF－8、UTF－16BE（使用BIG_ENDIAN）、UTF－16LE（使用LITTLE_ENDIAN）、UTF－16（使用一个字节顺序标志）
java.nio.charset	CharsetEncoder， CharsetDecoder	CharsetEncoder是一个引擎，它把一组16位的Unicode字符编码（或转换）为一个具体的由具体字符集指定的字节序列。CharsetDecoder执行相反的操作

续表

程序包	类/接口	描述
java.nio.charset	CoderResult	这个类报告一个编码器或解码器的状态。报告下面5种状态之一：错误、形式错误、下溢、上溢和无法映射
java.nio.charset	CodingActionError	这个类是一个类型安全的枚举，用于指定编码器或解码器应该如何处理错误。它可以被设置为IGNORE、REPLACE或REPORT