Given that new PCs tend to come with 64 bit windows 7 and that engineers
usually need to build the 32 bit JDK its a requirement that this be possible.
However a couple of things prevent this.

1) Hotspot's build ignores any setting of ARcH_DATA_MODEL and insists
that a 64 bit OS must mean you want to build 64 bit hotspot.
This could occur when trying to build 32 bit JDK on any 64 bit Windows.

2) A couple of identical bugs in security related makefiles where
the build is set to place generated class files in a temp directory
and then javah is run but not configured to look properly for these
class files this location.
The details of when this is a problem are a bit complicated

* This would not actually occur if a 32 bit JDK were being used to
do the compilation, as in that case the classes are found on
the boot class path of the bootstrap JDK. Of course if anyone
is actually modifying those classes in a away that affects
JNI calls, then this will be a problem in that case too.
At least one security engineer has reported having to work
around this problem.

* This doesn't occur in 64 bit builds because the related
makefiles are skipped in those builds.

So one could work around this by using 32 bit JDK's to
compile 32 bit JRE, but there is no valid reason I can think
of why that has to be the case, and 64 bit Windows OSEs
may be configured with either .. having to specifically
use the 32 bit one is an ease of use issue and this is a
rather mysterious error in code few people have experience in.