Java Zero Size Class Files

There is a rare problem that may occur with very large java projects in which class files of zero size are left in JAVACLASSDEST after a package build completes. During the java build process, nmake touches the class files before the javac compilation according to the classes set in localjavadeps. However, some of the class files JavaDeps lists in localjavadeps may have different names than what is generated by javac, which causes zero size class files.

Below is an example to illustrate the problem:

Suppose there is a java file named org/project/pkg/abc.java with corresponding class files listed by JavaDeps in localjavadeps of abc$1.class and abc.class. Javac actually creates files abc$2.class and abc.class. Thus after the package build the following three class files are found in the corresponding class directory, abc$1.class (zero-size), abc$2.class (not null) and abc.class (not null).

It is also noticed when javac is made to compile just the single java file abc.java, abc$1.class and abc.class will be created instead of abc$2.class and abc.class. Therefore the problem appears to be from inconsistent and unpredictable behavior in current versions of the javac SDK (jsdk1.3.0 and jsdk1.4.0). The problem can be found only in very large batch compilations and we have been unable to reproduce it in a simplified case.

The secondary class files are listed in localjavadeps so the dependencies can be properly tracked. When this problem arises the correct secondary class file, abc$2.class, is not tracked in localjavadeps. If abc$2.class is deleted between builds such that the main class file, abc.class, remains, then a rebuild may not regenerate the secondary class file. Since there is no dependency information for abc$2.class in localjavadeps nmake will not know to regenerate the file. It will only be regenerated if abc.class happens to be remade for another reason. The zero-length class files are by themselves harmless.