JDK-7076394 : Update RMI documentation to clarify that remote objects are exported to the wildcard address
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.rmi
  • Affected Version: 8
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2011-08-08
  • Updated: 2013-09-12
  • Resolved: 2013-08-02
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Related Reports
Relates :  
Relates :  
If UnicastRemoteObject is extended without specifying a server socket factory then the remote object is exported to the wildcard address. This bug requests that the specification for these methods be clarified to make it clear that the object is exported to all local addresses. The javadoc should also be updated to include an example that uses a server socket factory such as the following:

   static class MyFactory implements RMIServerSocketFactory {
        private final InetAddress addr;
        MyFactory(InetAddress addr) {
            this.addr = addr;
        public ServerSocket createServerSocket(int port) throws IOException {
            return new ServerSocket(port, 0, addr);
        public int hashCode() {
            return addr.hashCode();
        public boolean equals(Object obj) {
            if (obj == this) {
                return true;
            } else if (obj == null || getClass() != obj.getClass()) {
                return false;
            MyFactory other = (MyFactory) obj;
            return addr.equals(other.addr);

This bug has been re-purposed to cover changes to the RMI web documentation. Changes to the UnicastRemoteObject javadoc are covered by JDK-8020854. The wildcarding issue should be addressed by changes to the RMI Specification in sections 2.5, 5.3, and 5.8. Probably a brief mention or description of the issue is sufficient, not a new chapter or anything. I will supply proposed wording. I looked at the potential for changing other RMI docs, such as "Using Custom Socket Factories with Java RMI" or the RMI Trail of the Java Tutorial. They have example code that is suitable for modification, but making those changes and explaining them would disrupt the flow of the examples presented in those documents. So, I don't think those documents should be changed. It would seem reasonable to add a note on this topic to the "Create and export a remote object" section of the "Getting Started" tutorial.

JUSTIFICATION Priority changed from [] to [3-Medium] Developer should be clear that the object is exported to all local addresses. alan.bateman@oracle.com 2011-08-08 18:52:11 GMT

There are a couple socket factory alternatives. One is to use the "global" RMISocketFactory. The other is to use the socket factory pair (RMIClientSocketFactory and RMIServerSocketFactory) that can be passed to UnicastRemoteObject.exportObject(). Using the factory pair is more flexible in that it allows different objects to be exported on different sockets bound to different interfaces. However, it's complicated by the requirement to provide an RMIClientSocketFactory as well. This implementation must be serializable (since it's stored into the stub) and as such it cannot be defined as an anonymous inner class. This isn't a huge complication, but it does make things a bit confusing. An alternative to using one of the socket factories is to set up a security policy that accepts incoming connections only from specific internet addresses or domains.