What goes on when you push the Make button on JBuilder's toolbar? There are a lot of sophisticated features that many JBuilder users are familiar with. Let us take you on a tour of the hidden benefits you may have been ignoring in JBuilder's Java^TM compiler.

Overview of the Make Process

Whether you press the Make button on the toolbar, select the Project|Make Project menu item, or press the Ctrl-F9 key with the CUA keybinding, the effect is the same: JBuilder attempts to do whatever is necessary to bring your output path up to date.

Everything you have added to the project is considered as a part of the process. Images and other resources may be copied, RMI and IDL pre-processing may take place, but the heart of any project will be the packages and Java files you have added. The JBuilder Java compiler starts with these "compile roots" and starts to work its magic.

For each Java file, JBuilder checks to see if it needs to be compiled. There are several possible reasons for recompiling the source:

• One or more of the class files the source would produce are missing
• The source has been modified since it was last compiled
• One or more of the classes that the source produces depends on a member in another class that has changed

It is this last part of the process that makes JBuilder unique. A change in one source file may change the way other source files are compiled. Not only does JBuilder detect this situation, it is also capable of noticing when a change in one source would not affect other files because they refer to portions that have not changed. In this case it is smart enough not to recompile files unnecessarily.

Yes! Compiling everything in a large project takes a long time, but compiling only the files you have changed may fail to detect compile-time problems or even create runtime problems that will appear later. JBuilder knows exactly what files to recompile for you.

As part of the compilation process, JBuilder recursively checks every reference to another class. If code being compiled refers to another class that is out of date according to the same rules, it includes the referenced class in the compilation process.

Yes! JBuilder can compile an arbitrary set of source files with mutual interdependencies without needing to know what order to compile files in.

The JBuilder Project Revisited

From a conceptual standpoint, a JBuilder project consists of the following things:

• A target JDK for which the code is being developed
• A set of libraries containing classes the project references
• The source path containing the project's Java source code
• The output path where JBuilder should place compiled class files
• Individual files added for easy browsing and defining "compile roots"

Many first-time JBuilder users assume that all of their source files need to be added manually to a project. This isn't the case! You can create a new project, define the project's source path, and add the single source file or package that contains your application's main method. The JBuilder dependency checker will automatically compile and keep up to date any classes you refer to.

Yes! Once you know the rules, JBuilder projects are easy to set up for even the most complex projects, and they don't require a lot of maintenance to keep them up to date.

There are two situations where the default configuration may not be sufficient.

• If you use dynamic class lookup with something like Class.forName() you should explicitly add the classes that may be loaded to your project. The dependency checker has no way of knowing how to find these classes without this hint.
• If your project contains more than one package, JBuilder projects are configured by default to take a shortcut in dependency checking that may eliminate cross-package dependencies. As discussed below, this is easy to change, and you may want to make the new settings your default for new projects.

Configuring the Make Process

The "Project|Project Properties..." menu option gives you control over several groups of settings, including a full tab of "Compiler" settings. The options that give you control over the dependency checker are discussed in detail below. You can also alter the settings used when creating new projects by selecting the "Project|Default Project Properties..." menu option.

The "Check stable packages" and "Make stable packages" options work together to try to shorten the dependency checking process. The out-of-the-box configuration, with the former unchecked and the latter checked, shortens the make process at the expense of accuracy. Checking the former and unchecking the latter will allow cross-package dependency checking, and due to improvements made in JBuilder when creating the Foundation edition, this will still be fast enough for every day use.

The final dependency checking option is one of my personal favorites, and deserves its own heading.

The 'Synchronize Output Dir' Option

When I first discovered Java I was overjoyed. Even though the tools at the time were primitive, the development experience was fantastic... until you removed or renamed a class without getting rid of the corresponding class file.

Why is this a problem? Because as far as the compiler is concerned, the existence of that class file was proof positive of the class' existence. Any references to the outlaw class that I had forgotten still compiled. And they still ran, executing some code I had long since abandoned. I thought 'Now here is my first requirement when selecting a Java IDE. It has to delete these out-of-date classes automatically!'

When you turn on the 'Synchronize Output Dir' option, JBuilder takes care of the situation automatically. The first time it performs a dependency check on a class in a package it also removes any class files from your output directory that don't have a matching definition on your source path.

Yes! Those outstanding references to nonexistent classes get caught the next time you recompile, saving an amazing amount of time and effort trying to debug code that isn't there.

Until the Next Time

I hope this tour of the dependency checker has given you a greater appreciation of the technology at work behind the scenes on your behalf. We've always put a lot of time and effort into features that aren't necessarily sexy, they're just enormous productivity boosts for the Java developer. We believe that this is what really counts, and I hope you agree with us