java rmi -Djava.rmi.server.hostname=localhost still opens a socket listening on 0.0.0.0

Question

I use the -Djava.rmi.server.hostname=localhost option to make rmi listen on localhost only, but netstat shows the socket is listening on 0.0.0.0.

Answer 1

I assumed that if I set -Djava.rmi.server.hostname=localhost it should only be listening on 127.0.0.1

No.

Am I misunderstanding what java.rmi.server.hostname controls?

Yes. java.rmi.server.hostname has nothing whatsoever to do with what IP address the remote object listens on. That is determined by the RMIServerSocketFactory.

To correct the misquotation from my book in another answer (subsequently deleted):

java.rmi.server.hostname: Hostname string; default value is the local host's IP address in "dotted-quad" format ... which is embedded into remote stubs created by this JVM when remote objects are exported. This can be used to control the effective IP address of RMI servers exported by multi-homed hosts. This property is read exactly once in the life of the JVM.[1]

To expand on that, it can also be used to control the effective IP address (as seen by clients) of RMI servers exported by hosts that are behind NAT devices. It doesn't necessarily have anything to do with the local host, e.g. in NAT situations, and it can be either a hostname, a dotted-quad IPv4 address, or an IPv6 address.

[1] Pitt & McNiff, java.rmi, The Remote Method Invocation Guide, Addison Wesley 2001, p.258.

Answer 2

Since Java 8u102 -Dcom.sun.management.jmxremote.host binds to the special ip address.

Answer 3

Having run into this issue myself, I wanted to provide a different context to explain what this value is to those that are familiar with how HTTP works. When you initially connect to the port specified by com.sun.management.jmxremote.port, the response is effective the same as an HTTP redirect to the name formed by: java.rmi.server.hostname:com.sun.management.jmxremote.rmi.port. This means that the hostname must be a) resolvable by the JMX client, and b) permitted via routing and firewalls to be connected to. The port can overlap with the initial port that provides the redirect as well however.

Now, the question is: Can you prevent the redirect? As best I can tell, no. I have tried setting the hostname to various values such as 0.0.0.0, 255.255.255.255, '' (empty). I've set the port to "0" as well, to see if this impacts the behavior. Nope. Despite the fact that you CAN connect to the same port for the lookup and the RMI portion of the protocol, it doesn't let you just establish the connections to the same resolved IP.

I assume that this behavior is to allow a process to act as a central index for RMI ports for multiple processes or many nodes of a cluster, but with NAT, it is just an irritating relic of days long past in protocol design.