You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@river.apache.org by Peter Firmstone <ji...@zeus.net.au> on 2010/06/14 07:18:05 UTC
Replace RemoteException with IOException
Hi,
I've been having some thoughts about what Chris said about using
IOException where possible for clients using non remote classes and
interfaces, instead of RemoteException.
We have plenty of methods that declare they throw RemoteException, we
could change them to declare throws IOException, without breaking binary
compatibility as it doesn't change the method signature. We can
continue throwing a RemoteException, but just change the declaration, so
clients using non remote interfaces and classes can catch an
IOException, without needing to create any dependency on
java.rmi.RemoteException.
Thoughts?
Peter.
Re: Replace RemoteException with IOException
Posted by Peter Firmstone <ji...@zeus.net.au>.
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
>
>
Re: Replace RemoteException with IOException
Posted by Peter Firmstone <ji...@zeus.net.au>.
Sim IJskes - QCG wrote:
> On 06/14/2010 01:15 PM, Patrick Wright wrote:
>> 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
>
> The superclass would not solve the problem of the broken java (clones)
> with the missing java.rmi.* package. Or was there another reason for
> doing this? It is a convention, but still one that is verified by the
> export AFAIR. And if one is thrown (RemoteException) and it is
> de-serialized we need to intercept the deserialization at the client
> side in order to change to class reference. So if we want deployment
> on non-java.rmi platforms. we need to do away with it at both the
> server and the client side.
>
> Gr. Sim
>
Ok, probably sounds like I'm off on some crazy tangent somewhere, Java
CDC 1.11 Personal Basis Profile includes RemoteException, so this isn't
related to that, it's just an observation.
We can intercept Objects during Serialization and Deserialization and
change the class etc, done it already with MarshalledInstance and
MarshalledObject, for both input and output streams. But I wouldn't
want to make a habbit of it. The reason I did that is that the Entry
spec needs the MarshalledObject serialized form and all I can send is
MarshalledInstance, so I converted it without having MarshalledObject.
Serialized form is just bytes, bytecode isn't required.
Still I've had some thoughts about Android, like hedging one's bets, it
would be just too bad I suppose if we couldn't support dynamic
classloading on that platform if it really takes off. Surrogate will
work, don't know whether it would catch on though. Yeah you can
dynamically load dalvic files packaged in a jar file with URLClassLoader.
If we could convince Google to include this nice little two line class,
won't take up much room, honest:
package java.rmi;
public interface Remote {}
It could be done by translating the exceptions. It just wouldn't feel
right to get rid of java.rmi.Remote however.
Android has this ominous little warning:
*Warning:* security managers do *not* provide a secure environment for
executing untrusted code. Untrusted code cannot be safely isolated
within the Dalvik VM.
But reading about it further, Android just has a different declarative
security model, Permissions are declared in Manifests and applications
need to be signed.
http://developer.android.com/guide/topics/security/security.html
Re: Replace RemoteException with IOException
Posted by Sim IJskes - QCG <si...@qcg.nl>.
On 06/14/2010 01:15 PM, Patrick Wright wrote:
> 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
The superclass would not solve the problem of the broken java (clones)
with the missing java.rmi.* package. Or was there another reason for
doing this? It is a convention, but still one that is verified by the
export AFAIR. And if one is thrown (RemoteException) and it is
de-serialized we need to intercept the deserialization at the client
side in order to change to class reference. So if we want deployment on
non-java.rmi platforms. we need to do away with it at both the server
and the client side.
Gr. Sim
Re: Replace RemoteException with IOException
Posted by Patrick Wright <pd...@gmail.com>.
> 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
Re: Replace RemoteException with IOException
Posted by Peter Firmstone <ji...@zeus.net.au>.
Sim IJskes - QCG wrote:
> On 06/14/2010 07:18 AM, Peter Firmstone wrote:
>> I've been having some thoughts about what Chris said about using
>> IOException where possible for clients using non remote classes and
>> interfaces, instead of RemoteException.
>
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.
Eventually at some later date in the future (say 5years) another
implementation would have the freedom to throw an IOException instead.
Just thought it would be better if over time the API in River that
doesn't include java.rmi.Remote in it's interface declare it throw a
more appropriate Exception.
Won't break anything if the implementation doesn't change, not a biggie
if we don't do it either.
Just a thought.
Peter.
> It still would not work would it? Will a java.rmi.* package ever be
> downloaded from a non-local codebase (loaded through other than system
> classloader)?
>
> Gr. Sim
>
Re: Replace RemoteException with IOException
Posted by Sim IJskes - QCG <si...@qcg.nl>.
On 06/14/2010 07:18 AM, Peter Firmstone wrote:
> I've been having some thoughts about what Chris said about using
> IOException where possible for clients using non remote classes and
> interfaces, instead of RemoteException.
It still would not work would it? Will a java.rmi.* package ever be
downloaded from a non-local codebase (loaded through other than system
classloader)?
Gr. Sim