In addition to fixing in the javadoc the issue in the RMI spec documented as 4291592-- that the java.rmi.registry.Registry interface does not specify the behavior for certain null and empty string argument values-- the Registry javadoc has some other significant problems that should be fixed:

- It specifies that the "name" arguments passed to its methods are expected to be URL-formatted, which is not true-- that only applies to java.rmi.Naming.

- It specifies that the bind, rebind, and unbind methods throw MalformedURLException; they do not.

- It's class javadoc refers users to java.rmi.Naming, which it should probably not do, because we would prefer that users did not use the Naming API.

- It's class javadoc contains a paragraph that begins as follows:

Typically, a "registry" exists on every node that allows RMI connections
to servers on that node.

This statement promotes two significant misconceptions:

1) that a registry must be running on any host in which remote object are exported, and by extension, remote objects must always be bound and looked up via such a registry-- when in fact, a registry is only necessary for bootstrapping, and remote object can easily be exported on hosts without a registry and freely passed around as remote arguments and return values

2) that a registry even must be the means of bootstrapping (locating the first RMI stub)-- the registry is but a simple way of doing that, but there are plenty of other alternatives, such as JNDI or Jini based lookups, that are arguably more appropriate for certain applications. (Yes, the "Typically" is a bit of an escape hatch from this misconception, but the emphasis should be changed to further clarify reality.)