Customizing the Java Tools Library

Once you've mastered the foregoing, you can then start creating your own ToolPak to reduce or completely eliminate duplicate code. For example, you can create an alias for SYSTEM.OUT.PRINTLN (), reducing the amount of code that you type repeatedly. It can be part of a package called 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); }
} ///:~

All the different data types can now be output in a new row (P.rintln ()) or not in a new row (P.rint ()).
You may suspect that the directory where the file resides must start at a classpath location and continue com/bruceeckel/tools. Once compiled, an import statement is used to use the P.class file anywhere in your system. As shown below:
Tooltest.java
So from now on, whenever you make a useful new tool, you can add it to the tools directory (or your own personal util or tools directory).

1. The trap of Classpath
The P.java file has a very interesting trap. Especially for early Java implementations, the correct setting of classpath is often a difficult task. When I wrote this book, I introduced the P.java file, which initially seemed to work quite normally. In some cases, however, interruptions are beginning to occur. For a long time, I was convinced that it was Java or something else that was wrong when it was implemented. But in the end, I finally found that a program was introduced in one place (that is, the Codepackager.java in chapter 17th), which uses a different class p. Because it is used as a tool, it sometimes goes into the classpath; But as soon as it enters the classpath, if the executing program needs to look for classes in Com.bruceeckel.tools, Java first finds the P in Codepackager.java. At this point, the compiler reports that a particular method was not found. This is, of course, very frustrating because we see this approach in the previous class P, and there's no more diagnostic reports that give us a clue as to what we find in a completely different class (that's not even public).
At first glance, this seems to be a compiler error, but if you look at the import statement, you'll find that it simply says, "You might find p here." However, we assume that the compiler searches for its own classpath anywhere, so once it finds a P, it uses it, and if the "wrong" one is found during the search, it stops searching. This is slightly different from what we described earlier, because there are some annoying classes that are in the package. And here's a p that's not in the package, but it can still be found in the normal classpath search.
If you encounter situations like this, make sure that there is only one class for each name in the classpath.