This is yet another case where rmic will generate code that will not compile
with javac if the user does not follow the recommended JLS package name and
usage conventions; I'd rate this one as somewhat higher priority priority than
the similar 4114502. Again, stealing the description to the response on
RMI-USERS:

. . .

> We have a problem with using rmic in JDK 1.2 when we use the
>standard option of targeting JDK 1.1 and JDK 1.2, we get the
>following error
>
>D:\BUILD>rmic AgentServer.AgentServer
>D:\BUILD\AgentServer_Skel.java:177: Class AgentServer.AgentServer. AgentServer
n
>ot found.
> AgentServer.AgentServer server = (AgentServer.AgentServer) obj;
> ^
>D:\BUILD\AgentServer_Skel.java:177: Class AgentServer.AgentServer. AgentServer
n
>ot found.
> AgentServer.AgentServer server = (AgentServer.AgentServer) obj;
> ^
>2 errors
>
>
> Could this be because our remote implementation has the same
>name as its package? The stub compiles OK. If we change the
>AgentServer.AgentServer in the code above to just AgentServer we
>can then compile the Skeleton OK.
 
Interesting situation. You have run into an rmic bug, and your
analysis is correct: the problem is a result of the fact that your
class name and package qualifier are identical; removing that condition
should make the errors go away.
 
rmic takes the simple approach of always using fully qualified class
names in the Java code that it generates. There is a problem with that
approach is this rare situation, though: the Java Language rules for
resolving ambiguous dot-separated names prefer matching names to the
left of a dot with class names defined or explicitly imported into the
current source file, or defined in the same package, before considering
them as package names (see section 6.5.2 of the JLS). Thus, if the
fully-qualified name of a class that has the same name as its package
qualification is used in the source code of some class in the same
package, like rmic is doing here, the Java compiler will not understand
it as such a fully-qualified class name. In your case, it thinks that
"AgentServer.AgentServer" refers to a (non-existent) nested class names
AgentServer in the outer class AgentServer (which is in the package
AgentServer).
 
So this is a bug with the way rmic is generating Java code; to be safe,
it should probably not use package qualifications for the names of
classes that are in the same package as the class it is generating.
This situation is rare, however, because it will not occur if the
recommended standard Java naming conventions are followed (see section
6.8 of the JLS), where package names are almost always lowercase and
class names are always mixed case.
 
-- Peter