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. _______________________________________________ Classpath mailing list [email protected] http://lists.gnu.org/mailman/listinfo/classpath
