Relates :
|
|
Relates :
|
|
Relates :
|
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
|