As part of the JDK/JAE build there are stub files generated via the javah utility. Currently (1.1.4 and 1.2beta) the utility does not generate a new
stub file if the newly created file will be the same as the current file
(if it exists). The logic in javah is to create the stubs in a temporary file
and compare with the original -- if different then don't replace existing file.

There's a snag with the Win32-style (and probably Solaris) of build which causes endless rebuilding once something has gotten out of step.

Ideally, javah should have an option to force the generated of the stub files
even if there are no changed -- I've submitted another bug/rfe requesting this
(4085685).

------------

I was unable to access bugtraq this morning as there appears to be a job
locking a number of tables. Anyway, the problem usually appears at random
times after a build has aborted for some reason -- however it's very easy to
duplicate as follows (in fact anything that causes a .java or .class file to
be updated will lead to this scenario) :-

1. Assume that you have successfully completed a Win32 build via nmake
2. cd classes\java\awt
3. touch *.class
4. cd ..\..\..
5. nmake

// As class files have been updated the build will now attempt to generate
// new stubs using javah.exe to create libstubs.c

// Next the build will re-compile dependencies of libstubs.c

// Re-link of winawt.dll

// etc. done

6. At this point we have done a re-build so another nmake should not yield any
work to be done but...

7. Run nmake again and it will attempt to regenerate stubs, re-compile
libstubs.c, relink winawt.dll etc.


If you repeat step 7 the same will happen. Basically the issue is that make
assumes that an action will update the target of the rule but javah does not
work well with make files because it generates its results to a temporary file
first to see if there are any differences - if there is no differences then it
just deletes the temporary file and the target is not re-written. Thus when
make is re-run it will repeat the rule because it thinks that the target is
out of date.

My suggested fix is simply to "touch" the results of javah so that the
timestamp is updated. I have also logged an RFE against javah to suggest that
a -force option be included to force javah to generate an output file. I've
included the suggested code in the RFE.