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 32bit values of the
SHA1 message digest. If the result of the message digest, the five
32bit 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
