Using imports to change behavior

Using imports to change behavior

A feature that is missing from Java is C's conditional compilation, which allows you to change a switch and get different behavior without changing any other code. The reason such a feature was left out of Java is probably because it is most often used in C to solve cross-platform issues: different portions of the code are compiled depending on the platform that the code is being compiled for. Since Java is intended to be automatically cross-platform, such a feature should not be necessary.

However, there are other valuable uses for conditional compilation. A very common use is for debugging code. The debugging features are enabled during development, and disabled for a shipping product. Allen Holub (www.holub.com) came up with the idea of using packages to mimic conditional compilation. He used this to create a Java version of C's very useful assertion mechanism, whereby you can say "this should be true" or "this should be false" and if the statement doesn't agree with your assertion you'll find out about it. Such a tool is quite helpful during debugging.

Here is the class that you'll use for debugging:

This class simply encapsulates boolean tests, which print error messages if they fail. In Chapter 9, you'll learn about a more sophisticated tool for dealing with errors called exception handling, but the perr( ) method will work fine in the meantime.

When you want to use this class, you add a line in your program:

To remove the assertions so you can ship the code, a second Assert class is created, but in a different package:

Now if you change the previous import statement to:

The program will no longer print out assertions. Here's an example:

By changing the package that's imported, you change your code from the debug version to the production version. This technique can be used for any kind of conditional code.

Package caveat

It's worth remembering that anytime you create a package, you implicitly specify a directory structure when you give the package a name. The package must live in the directory indicated by its name, which must be a directory that is searchable starting from the CLASSPATH. Experimenting with the package keyword can be a bit frustrating at first, because unless you adhere to the package-name to directory-path rule, you'll get a lot of mysterious run-time messages about not being able to find a particular class, even if that class is sitting there in the same directory. If you get a message like this, try commenting out the package statement, and if it runs you'll know where the problem lies.