A custom tool library

A custom tool library

With this knowledge, you can now create your own libraries of tools to reduce or eliminate duplicate code. Consider, for example, creating an alias for System.out.println( ) to reduce typing. This can be part of a package called tools:

All the different data types can now be printed out either with a newline (P.rintln( )) or without a newline (P.rint( )).

You can guess that the location of this file must be in a directory that starts at one of the CLASSPATH locations, then continues com/bruceeckel/tools. After compiling, the P.class file can be used anywhere on your system with an import statement:

So from now on, whenever you come up with a useful new utility, you can add it to the tools directory. (Or to your own personal util or tools directory.)

Classpath pitfall

The P.java file brought up an interesting pitfall. Especially with early implementations of Java, setting the classpath correctly is generally quite a headache. During the development of this book, the P.java file was introduced and seemed to work fine, but at some point it began breaking. For a long time I was certain that this was the fault of one implementation of Java or another, but finally I discovered that at one point I had introduced a program (CodePackager.java, shown in Chapter 17) that used a different class P. Because it was used as a tool, it was sometimes placed in the classpath, and other times it wasn't. When it was, the P in CodePackager.java was found first by Java when executing a program in which it was looking for the class in com.bruceeckel.tools, and the compiler would say that a particular method couldn't be found. This was frustrating because you can see the method in the above class P and no further diagnostics were reported to give you a clue that it was finding a completely different class. (That wasn't even public.)

At first this could seem like a compiler bug, but if you look at the import statement it says only "here's where you might find P." However, the compiler is supposed to look anywhere in its classpath, so if it finds a P there it will use it, and if it finds the "wrong" one first during a search then it will stop looking. This is slightly different from the case described on page 196 because there the offending classes were both in packages, and here there was a P that was not in a package, but could still be found during a normal classpath search.

If you're having an experience like this, check to make sure that there's only one class of each name anywhere in your classpath.