Package name java.rmi
Sun's Spec Issues
This is the list of unspecified issuesRemote References Serialized Form
In the Remote Object Serialized Form API, (http://java.sun.com/j2se/1.5.0/docs/api/serialized-form.html#java.rmi.server.RemoteObject) it is specified that for UnicastRef and UnicastRef2 "the boolean value false, written by DataOutput.writeBoolean(boolean)" must be written when serialization of the remote reference occurs, but it is not specified the purpose of this value.
Deficiencies in RMI (JRMP) wire protocol specification
In the Java Remote Method Invocation Specification's Chapter 10, "RMI Wire Protocol", the "endpoint negotiation" for the StreamProtocol and the MultiplexProtocol is described tangentially and vaguely in section 10.2.1. The wire format of the described EndointIdentifier is not specified, and this piece of the protocol is not well integrated into the surrounding description. For further details see: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4674902
Wrong protocol version specified
The "Version" component of the connection header sent by the client is specified (in section 10.2.1) to be the literal sequence of octets 0x00 0x01. As stated by Bug Report Nº 4674902, this sequence has always been 0x00 0x02 since RMI first version. The specification should note that 0x00 0x02 is the only value of "Version" supported, because no FCS version of RMI (JRMP) has ever supported 0x00 0x01.
RMI through firewalls via proxies
RMI specification states that, when using HTTP to transport RMI calls, a proxy server must be used in order to redirect the call to the appropriate RMI server. From Section 3.5: "As described in this section, the HTTP-based mechanism that the RMI transport layer uses for RMI calls only applies to firewalls with HTTP proxy servers." But it does not specify any property in which the address of the proxy server should be set. Is not clear if this value should be implementation-specific, or if the system property "http.proxyHost" should be used, as suggested in http://java.sun.com/developer/onlineTraining/rmi/RMI.html
Use of the ServerRef interface
The API Specification does not define the specific use for this interface. The method exportObject defined in this interface seems to be obsolete, since returns a RemoteStub object, and then only one of the possible exportation scenarios is covered by this method (all other exportation situations, returns a Remote object; therefore this method isn't suitable for implement them), for that reason the use of this interface seems to be unnecessary for exportation purposes.
RMIClassLoaderSpi.loadProxyClass
It is not clear from the API whether the terms "resolve", "define" are used in the same way as defined in the Class ClassLoader. The API differentiates two different behaviors, depending on whether the defaultLoader can resolve all the interfaces or the codebase ClassLoader can resolve all the interfaces. Form this point it is not clear if all the interfaces should be resolved be the same or different loaders.
ClassLoaderSpi
The API Specification always assumes that the property java.rmi.server.codebase is correctly set, and it does not specify what to do when returns null.
DGC sequenceNumber issue
In the API Specification for the java.rmi.dgc.DGC.clean() it is mentioned that when the boolean parameter strong is true the sequenceNumber the calling VM (with its corresponding VMID) should be remembered. This happens when a previously issued dirty call failed in that client. This implies that if the dirty call has been lost the server will never remove that sequenceNumber from its table. In the long run this implies that memory will be stored for objects which will never be reused.
Garbage Collector - VMID exchange issue
RMI API states that a client should use a null value if it is unable to generate a unique VMID; and then send the dirty call with that null VMID, in order to receive a VMID from the server. The only way to know if the generated VMID is somehow "unique" is calling the deprecated VMID.isUnique() method, as long the VMID constructor doesn't throw any exception (It always success). In addition, the API doesn't specify what should happen if the server is unable to generate a unique VMID too.
Difference between specified CGI path address when tunneling through HTTP
In section 3.5.4 "Configuring the Server" RMI Specification states that the alias path for the CGI script that redirects the RMI calls when tunneling through HTTP must be: "/cgi-bin/java-rmi.cgi". In section 10.4 "RMI's Use of HTTP POST Protocol" the specification states that "The URL specified in the post header" when tunneling through CGI should be: "http://
Use of the CGI-BIN script when tunneling through HTTP
In section 3.5.4 "Configuring the Server" the RMI Specification states that the CGI script used to redirect RMI calls must: "Invoke the local interpreter for the Java programming language to execute a class internal to the transport layer which forwards the request to the appropriate RMI server port." and "Defines properties in the Java virtual machine with the same names and values as the CGI 1.0 defined environment variables.". In addition "An example script is supplied in the RMI distribution for the Solaris and Windows 32 operating systems". Now, in bug report ID 4418631 "java-rmi.cgi missing on Win32 builds since 1.1.x", it is noted that "The file java-rmi.cgi seems to have slipped through the cracks. It is not included in Win32 builds since the 1.1.x releases." And the official response to that statement is "There is no value in fixing this bug given that this issue has been unresolved since 1.1.x and it has received no votes. There is a servlet solution which is a better solution anyway, so the java-rmi.cgi is not really needed." RMI specification does not mention anything about the servlet approach, and it is not clear whether another implementation should use the cgi or the servlet approach.
Other reported Specification issues
Last updated: Mar 17, 2006