Thanks Patrick, interesting comment...
From the link:
* Each method declaration in a remote interface or its
super-interfaces must satisfy the requirements of a /remote
method/ declaration as follows:
o A remote method declaration must include the exception
|java.rmi.RemoteException| (or one of its superclasses such
as |java.io.IOException| or |java.lang.Exception|) in its
throws clause, in addition to any application-specific
exceptions (note that application specific exceptions do not
have to extend |java.rmi.RemoteException|).
o In a remote method declaration, a remote object declared as
a parameter or return value (either declared directly in the
parameter list or embedded within a non-remote object in a
parameter) must be declared as the remote /interface/, not
the implementation class of that interface.
Evolution is a gradual process, just thought about putting some pieces
in place for later on, no breakages now.
Patrick Wright wrote:
Nope, only ever loaded locally. The API in question, doesn't extend remote,
I just thought it made more sense to declare it throws an IoException, even
if the implementation throws a RemoteException.
In fact many API methods throw a RemoteException because their
implementation use java.rmi.Remote. If an implementation was to use some
other method of network communication or language, then the IOException
might make more sense. RemoteException extends IOException, so new clients
would still catch the RemoteException since it's a subclass.
I don't know if it's an important point, but as far as I know, the
convention of throwing RemoteException (as opposed to just
IOException) is a very, very old part of the RMI (and later Jini)
spec. I think it would be odd to try and change this convention now.
OTOH, the specification specifically allows a superclass of
RemoteException to be used
http://java.sun.com/javase/6/docs/platform/rmi/spec/rmi-objmodel5.html
