自定义工具库
　　掌握前述的知识后，接下来就可以开始创建自己的工具库，以便减少或者完全消除重复的代码。例如，可为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目录）。
　　classpath的陷阱
　　p.java文件存在一个非常有趣的陷阱。特别是对于早期的java实现方案来说，类路径的正确设定通常都是很困难的一项工作。编写这本书的时候，我引入了p.java文件，它最初看起来似乎工作很正常。但在某些情况下，却开始出现中断。在很长的时间里，我都确信这是java或其他什么在实现时一个错误。但最后，我终于发现在一个地方引入了一个程序（即第17章要说明的codepackager.java），它使用了一个不同的类p。由于它作为一个工具使用，所以有时候会进入类路径里；另一些时候则不会这样。但只要它进入类路径，那么假若执行的程序需要寻找com.bruceeckel.tools中的类，java首先发现的就是codepackager.java中的p。此时，编译器会报告一个特定的方法没有找到。这当然是非常令人头疼的，因为我们在前面的类p里明明看到了这个方法，而且根本没有更多的诊断报告可为我们提供一条线索，让我们知道找到的是一个完全不同的类（那甚至不是public的）。
　　乍一看来，这似乎是编译器的一个错误，但假若考察import语句，就会发现它只是说：“在这里可能发现了p”。然而，我们假定的是编译器搜索自己类路径的任何地方，所以一旦它发现一个p，就会使用它；若在搜索过程中发现了“错误的”一个，它就会停止搜索。这与我们在前面表述的稍微有些区别，因为存在一些讨厌的类，它们都位于包内。而这里有一个不在包内的p，但仍可在常规的类路径搜索过程中找到。
　　如果您遇到象这样的情况，请务必保证对于类路径的每个地方，每个名字都仅存在一个类。