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