There are many issues with the way that the CClassHeaders are generated
from Rules.gmk, including:

1 The default combined effects of the following problems
is that for any given build touching an exported class,
the headers are regenerated using the debug javah_g
which is painfully slow (taking 20 times as long as
the optimized version).

2 When an exported class file is updated, the corresponding
CClassHeader is only regenerated on the second subsequent
build attempt. This can lead to inconsistent incremental
builds.

3 CClassHeaders are regenerated for both the optimized and
debug builds even though they are the same in both cases.

4 The CClassHeaders for the debug build are generated using
javah_g even though it adds no value for our build process
and takes 20 times (!) as long as javah (well over a minute
versus 3 seconds on an Ultra 60).

5 An annoying nit - the architecture name is appended to the
.class.headers filename even though different architectures
already build into different top-level directories.

6 In the rule to build CClassHeaders, the target only depends
on the contents of FILES_export even though additional
exported headers also exist in the FILES_export2 and
FILES_export3 variables in many subdirectories. Note
that the argument list for javah is built from all 3
macros so the dependencies should also lest we then
depend on out of date headers.

Problem 1 is really just a combination of 2, 3, and 4 and leads to
the impression that the javah step of our builds is a major problem
for our incremental builders.

Problem 2 is due to the fact that gnumake has already statted the
.class files in order to resolve the "classes" target by the time
it gets to evaluating the dependencies of the .class.headers target
and it failed to notice that javac caused some of the .class files
to change date. This can be fixed either by telling gnumake to
reevaluate the timestamps on the .class files in some manner (I'm
not sure if this capability exists), or by using recursion to
build the .class.headers target:

classheaders: classes $(CLASSHDRDIR)
gnumake <...the .class.headers file...>

Note that .class.headers no longer appears as a dependency of the
classheaders target in this mode. Hopefully there is simply a
way to tell gnumake that the .class files need to have their
timestamps reevaluated instead.

Problem 3 can be solved by using the same .class.headers file for
both builds. Currently that file is stored in the object directory
so it is different for both the optimized and debug builds and so
there are 2 such files that can be out of date per complete build
cycle and thus the classheaders need to be rechecked twice. Moving
the .class.headers file to the $(CLASSHDRDIR) and making it the
same between debug and optimized builds will cause the files to
only have to be checked once per exported class file change. If
some directory needs to have different exported classes in the
debug and optimized builds then we could add an option to have
separate .class.header targets for the two variants, but I don't
believe any such build modules exist so a common file should suffice.

Problem 4 can be solved by not having the JAVAH_CMD macro depend
on the optimized/debug suffix and always use the optimized javah
version. This change alone could make Problem 3 mostly
irrelevant as the optimized version goes pretty fast.

Problem 5 is simply unnecessary but doesn't hurt anything.

Problem 6 is unlikely to cause too many inconsistencies because
most of the locally exported files are usually stored in the
FILES_export variable and the export2 and export3 variables are
typically used to hold references to classes from other modules
from which typically we only import constants. Still, there
is a potential for an inconsistent build because of this.

Problems 2 and 6 can lead to inconsistent incremental builds and
so they are true bugs.

Problems 3 and 4 simply waste developers time.