按键盘上方向键 ← 或 → 可快速上下翻页，按键盘上的 Enter 键可回到本书目录页，按键盘上方向键 ↑ 可回到本页顶部！
————未阅读完？加入书签已便下次继续阅读！
找名称适当的已编译文件（对于Vector 是Vector。class，对于 List 则是List。class）。注意Vector 和
List 内无论类还是需要的方法都必须设为public。
1。 自动编译
为导入的类首次创建一个对象时（或者访问一个类的static 成员时），编译器会在适当的目录里寻找同名
的。class 文件（所以如果创建类 X 的一个对象，就应该是 X。class）。若只发现X。class，它就是必须使用
的那一个类。然而，如果它在相同的目录中还发现了一个 X。java，编译器就会比较两个文件的日期标记。如
果X。java 比X。class 新，就会自动编译 X。java，生成一个最新的 X。class。
对于一个特定的类，或在与它同名的。java 文件中没有找到它，就会对那个类采取上述的处理。
2。 冲突
若通过*导入了两个库，而且它们包括相同的名字，这时会出现什么情况呢？例如，假定一个程序使用了下述
导入语句：
import 。bruceeckel。util。*；
import java。util。*；
由于java。util。*也包含了一个Vector 类，所以这会造成潜在的冲突。然而，只要冲突并不真的发生，那么
就不会产生任何问题——这当然是最理想的情况，因为否则的话，就需要进行大量编程工作，防范那些可能
可能永远也不会发生的冲突。
如现在试着生成一个Vector，就肯定会发生冲突。如下所示：
Vector v = new Vector（）；
它引用的到底是哪个Vector 类呢？编译器对这个问题没有答案，读者也不可能知道。所以编译器会报告一个
错误，强迫我们进行明确的说明。例如，假设我想使用标准的 Java Vector，那么必须象下面这样编程：
java。util。Vector v = new java。util。Vector（）；
由于它（与CLASSPATH 一起）完整指定了那个Vector 的位置，所以不再需要 import java。util。*语句，除
非还想使用来自java。util 的其他东西。
5。1。2 自定义工具库
掌握前述的知识后，接下来就可以开始创建自己的工具库，以便减少或者完全消除重复的代码。例如，可为
System。out。println（）创建一个别名，减少重复键入的代码量。它可以是名为 tools 的一个包（package）的
一部分：
//： P。java
126
…………………………………………………………Page 128……………………………………………………………
// The P。rint & P。rintln shorthand
package 。bruceeckel。tools；
public class P ｛
public static void rint（Object obj） ｛
System。out。print（obj）；
｝
public static void rint（String s） ｛
System。out。print（s）；
｝
public static void rint（char＇＇ s） ｛
System。out。print（s）；
｝
public static void rint（char c） ｛
System。out。print（c）；
｝
public static void rint（int i） ｛
System。out。print（i）；
｝
public static void rint（long l） ｛
System。out。print（l）；
｝
public static void rint（float f） ｛
System。out。print（f）；
｝
public static void rint（double d） ｛
System。out。print（d）；
｝
public static void rint（boolean b） ｛
System。out。print（b）；
｝
public static void rintln（） ｛
System。out。println（）；
｝
public static void rintln（Object obj） ｛
System。out。println（obj）；
｝
public static void rintln（String s） ｛
System。out。println（s）；
｝
public static void rintln（char＇＇ s） ｛
System。out。println（s）；
｝
public static void rintln（char c） ｛
System。out。println（c）；
｝
public static void rintln（int i） ｛
System。out。println（i）；
｝
public static void rintln（long l） ｛
System。out。println（l）；
｝
127
…………………………………………………………Page 129……………………………………………………………
public static void rintln（float f） ｛
System。out。println（f）；
｝
public static void rintln（double d） ｛
System。out。println（d）；
｝
public static void rintln （boolean b） ｛
System。out。println（b）；
｝
｝ ///：~
所有不同的数据类型现在都可以在一个新行输出（P。rintln（）），或者不在一个新行输出（P。rint（） ）。
大家可能会猜想这个文件所在的目录必须从某个CLASSPATH 位置开始，然后继续/bruceeckel/tools。编
译完毕后，利用一个 import 语句，即可在自己系统的任何地方使用P。class 文件。如下所示：
//： ToolTest。java
// Uses the tools library
import 。bruceeckel。tools。*；
public class ToolTest ｛
public static void main（String＇＇ args） ｛
P。rintln（〃Available from now on！〃）；
｝
｝ ///：~
所以从现在开始，无论什么时候只要做出了一个有用的新工具，就可将其加入tools 目录（或者自己的个人
util 或tools 目录）。
1。 CLASSPATH 的陷阱
P。java 文件存在一个非常有趣的陷阱。特别是对于早期的 Java 实现方案来说，类路径的正确设定通常都是
很困难的一项工作。编写这本书的时候，我引入了 P。java 文件，它最初看起来似乎工作很正常。但在某些情
况下，却开始出现中断。在很长的时间里，我都确信这是 Java 或其他什么在实现时一个错误。但最后，我终
于发现在一个地方引入了一个程序（即第 17 章要说明的 CodePackager。java），它使用了一个不同的类P。
由于它作为一个工具使用，所以有时候会进入类路径里；另一些时候则不会这样。但只要它进入类路径，那
么假若执行的程序需要寻找。bruceeckel。tools 中的类，Java 首先发现的就是CodePackager。java 中的
P。此时，编译器会报告一个特定的方法没有找到。这当然是非常令人头疼的，因为我们在前面的类 P 里明明
看到了这个方法，而且根本没有更多的诊断报告可为我们提供一条线索，让我们知道找到的是一个完全不同
的类（那甚至不是public 的）。
乍一看来，这似乎是编译器的一个错误，但假若考察 import 语句，就会发现它只是说：“在这里可能发现了
P”。然而，我们假定的是编译器搜索自己类路径的任何地方，所以一旦它发现一个P，就会使用它；若在搜
索过程中发现了“错误的”一个，它就会停止搜索。这与我们在前面表述的稍微有些区别，因为存在一些讨
厌的类，它们都位于包内。而这里有一个不在包内的P，但仍可在常规的类路径搜索过程中找到。
如果您遇到象这样的情况，请务必保证对于类路径的每个地方，每个名字都仅存在一个类。
5。1。3 利用导入改变行为
Java 已取消的一种特性是C 的“条件编译”，它允许我们改变参数，获得不同的行为，同时不改变其他任何
代码。Java 之所以抛弃了这一特性，可能是由于该特性经常在 C 里用于解决跨平台问题：代码的不同部分根
据具体的平台进行编译，否则不能在特定的平台上运行。由于 Java 的设计思想是成为一种自动跨平台的语
言，所以这种特性是没有必要的。
然而，条件编译还有另一些非常有价值的用途。一种很常见的用途就是调试代码。调试特性可在开发过程中
使用，但在发行的产品中却无此功能。Alen Holub （holub。 ）提出了利用包（package）来模仿条件
编译的概念。根据这一概念，它创建了C “断定机制”一个非常有用的Java 版本。之所以叫作“断定机
128
…………………………………………………………Page 130……………………………………………………………
制”，是由于我们可以说“它应该为真”或者“它应该为假”。如果语句不同意你的断定，就可以发现相关
的情况。这种工具在调试过程中是特别有用的。
可用下面这个类进行程序调试：
//： Assert。java
// Assertion tool for debugging
package 。bruceeckel。tools。debug；
public class Assert ｛
private static void perr（String msg） ｛
System。err。println（msg）；
｝
public final static void is_true（boolean exp） ｛
if（！exp） perr（〃Assertion failed〃）；
｝
public final static void is_false（boolean exp）｛
if（exp） perr（〃Assertion failed〃）；
｝
public final static void
is_true（boolean exp； String msg） ｛
if（！exp） perr（〃Assertion failed： 〃 ＋ msg）；
｝
public final static void
is_false（boolean exp； String msg） ｛
if（exp） perr（〃Assertion failed： 〃 ＋ msg）；
｝
｝ ///：~
这个类只是简单地封装了布尔测试。如果失败，就显示出出错消息。在第 9 章，大家还会学习一个更高级的
错误控制工具，名为“违例控制”。但在目前这种情况下，perr（）方法已经可以很好地工作。
如果想使用这个类，可在自己的程序中加入下面这一行：
import 。bruceeckel。tools。debug。*；
如欲清除断定机制，以便自己能发行最终的代码，我们创建了第二个Assert 类，但却是在一个不同的包里：
//： Assert。java
// Turning off the assertion output
// so you can ship the program。
package 。bruceeckel。tools；
public class Assert ｛
public final static void is_true（boolean exp）｛｝
public final static void is_false（boolean exp）｛｝
public final static void
is_true（boolean exp； String msg） ｛｝