Question

掌握前述的知识后，接下来就可以开始创建自己的工具库，以便减少或者完全消除重复的代码。例如，可为 System.out.println() 创建一个别名，减少重复键入的代码量。它可以是名为 tools 的一个包（package）的一部分：

//: P.java
// The P.rint & P.rintln shorthand
package com.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);
  }
  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 位置开始，然后继续 com/bruceeckel/tools。编译完毕后，利用一个 import 语句，即可在自己系统的任何地方使用 P.class 文件。如下所示：

ToolTest.java

所以从现在开始，无论什么时候只要做出了一个有用的新工具，就可将其加入 tools 目录（或者自己的个人 util 或 tools 目录）。

1. CLASSPATH 的陷阱

P.java 文件存在一个非常有趣的陷阱。特别是对于早期的 Java 实现方案来说，类路径的正确设定通常都是很困难的一项工作。编写这本书的时候，我引入了 P.java 文件，它最初看起来似乎工作很正常。但在某些情况下，却开始出现中断。在很长的时间里，我都确信这是 Java 或其他什么在实现时一个错误。但最后，我终于发现在一个地方引入了一个程序（即第 17 章要说明的 CodePackager.java），它使用了一个不同的类 P。由于它作为一个工具使用，所以有时候会进入类路径里；另一些时候则不会这样。但只要它进入类路径，那么假若执行的程序需要寻找 com.bruceeckel.tools 中的类，Java 首先发现的就是 CodePackager.java 中的 P。此时，编译器会报告一个特定的方法没有找到。这当然是非常令人头疼的，因为我们在前面的类 P 里明明看到了这个方法，而且根本没有更多的诊断报告可为我们提供一条线索，让我们知道找到的是一个完全不同的类（那甚至不是 public 的）。

乍一看来，这似乎是编译器的一个错误，但假若考察 import 语句，就会发现它只是说：“在这里可能发现了 P”。然而，我们假定的是编译器搜索自己类路径的任何地方，所以一旦它发现一个 P，就会使用它；若在搜索过程中发现了“错误的”一个，它就会停止搜索。这与我们在前面表述的稍微有些区别，因为存在一些讨厌的类，它们都位于包内。而这里有一个不在包内的 P，但仍可在常规的类路径搜索过程中找到。

如果您遇到象这样的情况，请务必保证对于类路径的每个地方，每个名字都仅存在一个类。