Re: rmi vs cajo

[Andrew Haley]

Mark Wielaard writes:
 > Hi Andrew,
 > 
 > I CCed John Catherino the main Cajo developer. He might have more
 > insights (or correct me if I am just plain wrong about cajo).
 > 
 > On Tue, 2005-09-13 at 15:03 +0100, Andrew Haley wrote:
 > > Mark Wielaard writes:
 > >  > 
 > >  > While playing a bit with Cajo
 > >  > (http://wiki.java.net/bin/view/Communications/ProxyUsage) I got the
 > >  > following error:
 > >  > 
 > >  > java.lang.NullPointerException
 > >  >    at gnu.cajo.invoke.Remote.hashCode (Remote.java:510)
 > >  >    at java.util.Hashtable.hash (Hashtable.java:822)
 > >  >    at java.util.Hashtable.put (Hashtable.java:432)
 > >  >    at gnu.java.rmi.server.UnicastServer.exportObject 
 > > (UnicastServer.java:66=
 > >  > )
 > >  >    at gnu.java.rmi.server.UnicastServerRef.exportObject 
 > > (UnicastServerRef.j=
 > >  > ava:110)
 > >  >    at java.rmi.server.UnicastRemoteObject.exportObject 
 > > (UnicastRemoteObject=
 > >  > .java:83)
 > >  >    at java.rmi.server.UnicastRemoteObject.<init> 
 > > (UnicastRemoteObject.java:=
 > >  > 69)
 > >  >    at gnu.cajo.invoke.Remote.<init> (Remote.java:486)
 > >  >    at gnu.cajo.utils.ItemServer.bind (ItemServer.java:206)
 > >  >    at ProxyTest.main (ProxyTest.java:38)
 > >  > 
 > >  > It seems we are to eager to export the Remote object immediately (from
 > >  > the constructor). We want to put it in a Hashtable and call hasCode(),
 > >  > but for the cajo Remote object the item field used to calculate the
 > >  > hashCode() hasn't been set yet so that gives a NullPointerException.
 > > 
 > > Isn't this a simple failure by gnu.cajo.invoke.Remote to satisfy the
 > > contract for hashCode()?  As I understand it, hashCode() should not
 > > throw any exception.
 > 
 > Normally hasCode() should not. But I think we are a little evil here in
 > the UnicastRemoteObject constructor. I don't have the precise source
 > code here, but it looks something like:
 > 
 > class Remote extends UnicastRemoteObject
 > {
 >   private final string name;
 > 
 >   Remote(String name)
 >   {
 >     super(); // Either explicitly or implicitly.
 >     this.name = name;
 >   }
 > 
 >   public int hashCode()
 >   {
 >     return name.hashCode();
 >   }
 > }
 > 
 > And in UnicastRemoteObject initializer we are trying to call the
 > hashCode() of the not-really-fully-initialized-yet Remote object.
 > I am not sure how else cajo could do this, except special casing
 > hashCode() to expect being called from the (super-class) constructor
 > which seems terribly messy.

It does, but it is robust.  It seems that the real problem is that an
uninitialized object is being exported.

I see why an IdentityHashMap might be a solution.

Andrew.