Not to question RMI, but on matching methods with the same ordinal number, why not do this at deployment/startup time? As the client interface is fixed, we can have a mapping performed by alphabetically ordering the method signatures and then simply taking their indexes.
As the number of methods is fixed, we can utilise a static structure (i.e. an array) to hold the method metadata and methodproxies and utilise this index for a lookup (removes the need for continuous trie lookups or various other string manipulation). NOTE: if we take control of the stub generation, we can generate these indexes up front and thus require NO string manipulations. On Friday, September 5, 2003, at 08:16 AM, Hiram Chirino wrote: > I actually had to change the way that worked. Seems like the Method[] > the Class.getMethods() is in a different order if you run in different > JVMs. Well at least that's what I noticed. So for now I'm sending > down > a String the represents the method sig until I find a way to get an Int > to represent the method. > > So how can we get 2 jvms to agree on the same ordinal number mapping?? Use the RMI hashing algorithm: http://java.sun.com/products/jdk/1.2/docs/guide/rmi/spec/rmi- stubs.doc3.html the string containing the remote method's name and descriptor would be the following: myRemoteMethod(ILjava.lang.Object;Z)V The hash value is assembled from the first two 32-bit values of the SHA-1 message digest. If the result of the message digest, the five 32-bit words H0 H1 H2 H3 H4, is in an array of five int values named sha, the hash value would be computed as follows: long hash = ((sha[0] >>> 24) & 0xFF) | ((sha[0] >>> 16) & 0xFF) << 8 | ((sha[0] >>> 8) & 0xFF) << 16 | ((sha[0] >>> 0) & 0xFF) << 24 | ((sha[1] >>> 24) & 0xFF) << 32 | ((sha[1] >>> 16) & 0xFF) << 40 | ((sha[1] >>> 8) & 0xFF) << 48 | ((sha[1] >>> 0) & 0xFF) << 56; =dain
