Since the 1.2beta4-G probmoted build, the "rmiregistry" and "rmid" tools in the
JDK exhibit a significant change in behavior: they no longer will load classes
from locations specified by the CLASSPATH environment variable of the shell from
they were invoked from. "rmiregistry" has always seen classes in CLASSPATH when
unmarshalling types received over a remote call, and that behavior is highly
expected by users. Even though it's more general to have the registry download
stub classes from a codebase supplied by a server, the ability to have it find
classes in CLASSPATH is extremely common in typical small test situations as
well as some larger development scenarios.

The C code used to launch all of the JDK tools, located here:

src/share/bin/java.c

was changed for the 1.2beta4-G build to cause this bug. It was changed so that
if JAVA_ARGS is defined (by the tool's makefile) for the compilation, which
indicates that this launcher is for an "application" rather than simply the
"java" command, then instead of turning the CLASSPATH environment variable into
an option that defines the property "java.class.path" to its value, it defines
"java.class.path" to some APP_CLASSPATH thing (unnecessary for these tools),
and it only makes the value of the CLASSPATH environment variable known through
setting the "env.class.path" property. This means that the application class
loader not load from the CLASSPATH (since it doesn't translate to
"java.class.path"), and hence rmiregistry and rmid will not load classes from
there.