Re: rmi vs cajo

[john . catherino]

Hi Mark, Hi Andrew,

The cajo Remote constructor is very simple:

private final Object item;
public Remote(Object item) throws RemtoteException {
    super(rssf.port, rcsf, rssf); // assign socket factories
    this.item = item; // assign object to remote
}

and has the following implementation of hashCode:

public final int hashCode() { return item.hashCode(); }

There is no fancy footwork done in the constructor as you can see. It would 
seem the Sun (and IBM) RMI implementation logically must not call hashCode() 
during construction, because it works there. (while I have not looked into the 
Sun (or IBM) RMI code myself)

Highest regards,

John


> 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.