This is another bug where rmic can generate code that will not compile with
javac, but it only happens whn the user is doing somthing not recommended
anyway, so I'm filing this as a separate low priority bug. I'm stealing the
description from a response that I wrote on the RMI-USERS list:

. . .
 
You have indeed uncovered a bug in rmic. Since your server class is in
a named package, to make the resulting stub class compile successfully,
rmic should be generating explicit "import" statements for each class
to be named that is in an unnamed package, or else javac will expect
that an unqualified class name, like your "Message", refers to a class
in the same named package as your server (like you had to do yourself
in RMIServer.java to get it to compile in the first place).
 
I would argue, however, that this bug is fairly obscure because it
depends on the unorthodox way that you are mixing named and unnamed
packages together. You say that you "really do not want to put Message
into the Server package", but you do not say that Message *needs* to be
in an unnamed package; so, the obvious solution to recommend is to put
Message in some other, named package.
 
Generally, only small, self-contained example or test classes are put
in an unnamed package. Any more significant groups of classes are put
in named packages, to give them separate real namespaces and access
boundaries. Once a class is put in a named package, it is not
recommended (and highly uncommon) for it to refer to classes in an
unnamed package, because the behavior of unnamed packages is rather
vaguely defined, and a class that now has its own comfortable little
home in the real package namespace should not make its definition
dependent on something that must be found in the wild jungle that is
the space of unnamed packages, where everyone's nasty little test
classes lurk. The following is from the JLS, section 7.4.2: "...it is
strongly recommended that compilation units of named packages never
import types from unnamed packages. It is also recommended that any
type declared in an unnamed package not be declared public, to keep
them from accidentally being imported by a named package."
 
-- Peter
 
 
>D:\java\RMIServer_Stub.java:6: class Server.RMIServer_Stub must be
>declared abstract and not final. It does not define void
>postMessage(Message) from interface Server.RMIServerInt.
>public final class RMIServer_Stub
> ^
>D:\java\RMIServer_Stub.java:43: Class Server.Message not found in type
>declaration.
> public void postMessage(Message $_Message_1) throws
>java.rmi.RemoteException
>throws java.rmi.RemoteException {
> ^
> D:\java\RMIServer_Stub.java:49: Class Server.Message not found in void
>postMessage(Server.Message).
> out.writeObject($_Message_1);
> ^
>D:\java\RMIServer_Skel.java:41: Class Server.jpsMessage not found in
>type declaration.
> Message $_Message_1;
> ^
>D:\java\RMIServer_Skel.java:44: Class Server.Message not found in type
>declaration.
> $_Message_1 = (Message)in.readObject();
> ^
>D:\java\RMIServer_Skel.java:50: Variable $_Message_1 may not have been
>initialized.
> server.postMessage($_Message_1);
> ^
>6 errors