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
