> -Why is it a problem not having the stub on the client side? The client
> needs the interface anyway to
> compilae, so I don't see a situation where downloading the stub
> dynamically would be benefitial? (as you must copy the interface in
> advance, you can also copy the stub).
The stub *object* is downloaded dynamically but the stub *class* (.class
file) must be available at the client just like the interface .class
file. Using the java.rmi.server.codebase feature you can also download
the .class files. This is very handy in large-scale deployments, e.g.
JWS deployments.
> -When I launch a server that registers some object on the RMI
> subsystem, it remains executing (because it has objects referenced by
> the name server). I I kill the server (with CTRL-C), the objects will
> die but they will still be registered on the rmiregistry (as far as I
> understand...). Is there any way of performing an automatic unbind when
> killing the server?
No.
> -Performing a test where I download dynamically a stub, it fails (due
> to security restrictions) when I use a codebase starting with "file:\\"
> but it works if it starts just with "file:". I don't understand what's
> the difference...
Codebase is a URL and backslash is not a legal character in a URL.
> -I'm not sure if the exception propagation is automatic with RMI in the
> current version of Java, is it? For example, if executing the remote
> method a NullPointerException is launched, it will be automatically
> wrapped in a RemoteException? In Java 1.3, it wasn't.
The behaviour you describe for 1.3 is still the behaviour. It was
different in JDK 1.1.x, you got a ServerRuntimeException.
> -Is the rmiregistry implemented using JNDI?
No, but you can *access* it using JNDI. There's a difference.
> If so, I think one of the
> main inconveniences of the RMI name service (that it is a flat,
> non-hierarchical namespace) could be avoided by using JNDI with LDAP.
> Am I right?
Yes, but it doesn't follow from your premiss.
You could use LDAP *instead* of the RMI registry.