river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Firmstone <j...@zeus.net.au>
Subject Re: Replace RemoteException with IOException
Date Mon, 14 Jun 2010 13:04:14 GMT
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.


View raw message