8.1 ClearCase Build Problems with Java

Java source is kept in files with extension .java, where the file name must be constructed from the name of the class it defines. For example, a class ocean referenced by other Java source files must be in a file named ocean.java. Compiling ocean.java with the Java compiler creates a file called ocean.class. Subsequent compilations may read the .class files generated previously.

When the Java compiler encounters a reference to a class defined in another file, it rebuilds that class file if it is out of date or does not exist. This behavior puts extra information in the configuration record:

• Extra .class files as siblings of the target .class file

• Extra dependencies on .java sources from building the siblings

This information can cause unnecessary rebuilding, prevent winkins, and create confusing catcr output. The major Java development toolkits exhibit this behavior.

Java Toolkits

These are the major Java development toolkits:

• The standard Java toolkit is Sun's JDK, which includes the javac compiler and is available for many platforms.

• Microsoft provides its own extended version of the development kit, including the jvc.exe compiler, which is upward compatible with javac and has the same behavior. The Microsoft Visual J++ invokes jvc.exe and also has the same behavior, but does not use makefile-based building.

• Like Visual J++, Symantec Cafe invokes its own compiler (also called javac.exe) underneath. The Symantec compiler is fully compatible with the Sun compiler, and you can set up options in Cafe to use the Sun compiler instead. Cafe uses an internal dependency tracking mechanism to control rebuilds, without an external makefile format.

The remainder of this chapter uses javac from Sun as the example, but the discussion also applies to Microsoft jvc.exe and Symantec javac.exe.

Scope of the Problems

The build problems relate to conflicts between the dependency analyses of clearmake/omake and javac. Because the Java compiler does some dependency analysis, some developers may not require make tools. Environments such as Visual J++ do not require that you use makefiles, nor do they generate and use makefiles themselves as Visual C++ does.

The need for make tools is reduced further because the Java language minimizes the need to recompile a dependent class file when the depended-on file changes. Java keeps interface and implementation in the same file, so changes to the implementation part of the file do not strictly require recompilation. This behavior differs from C and C++ applications, in which interface is separated from implementation by splitting the source into header (.h) and implementation (.c) files. Some developers may prefer to control when to rebuild Java sources. However, none of the current tool environments is based on such a language-sensitive recompilation; like make, javac uses time stamps to determine when to rebuild.