Name: acR10002 Date: 04/18/2000


Current spec doesn't provide necessary restrictions on the code produced by rmic:

1. Specification for stub. The most detailed stub spec says (RMI spec v1.3 ch3.1):
------------------------------ RMI spec excerpt ---------------------------------
         When a stub's method is invoked, it does the following:
              initiates a connection with the remote JVM containing the remote object,
              marshals (writes and transmits) the parameters to the remote JVM,
              waits for the result of the method invocation,
              unmarshals (reads) the return value or exception returned, and
              returns the value to the caller.
---------------------------------------------------------------------------------
However, the means of initiating the connection, marshalling/unmarshalling arguments/results
are not documented. The fact that stub must only forward a call to underlying RemoteRef object
(in case of v1.1 stubs - write arguments to the RemoteCall object supplied by RemoteRef,
forward a call, read the result or exception from RemoteCall) is not specified.
The javadoc for java.rmi.server.RemoteRef says :
"A RemoteStub uses a remote reference to carry out a remote method invocation to a remote object",
but it doesn't prohibit any partial usage of the RemoteRef
(for example, creation of RemoteCall object not via RemoteRef.newCall()).

2. Specification for skeleton. rmic shipped with JDK produces the code for dispatch() method
which uses the streams provided by RemoteCall object passed. The spec doesn't say that namely
these streams should be used for writing results. Also, the spec is not clear
about which one of the streams (obtained with getOutputStream() or getResultStream())
should be used by a skeleton to write the result to.

In any case, the spec for stub/skeleton should document:
a) what methods of RemoteRef and RemoteCall are invoked
b) the sequence of invocation
The lack of the detailed specification leaves the possibility of generating stubs/skeletons
which are not compatible with reference implementation.

======================================================================