自界说java东西库

把握前述的常识后，接下来就可以开始建设本身的东西库，以便淘汰可能完全消除反复的代码。譬喻，可为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，但仍可在通例的类路径搜索进程中找到。
假如您碰着象这样的环境，请务必担保对付类路径的每个处所，每个名字都仅存在一个类。