Despite the fix for 4413822, the text in the RMI specification that defines the -v1.2 stub protocol's method hash computation is still flawed enough to make it difficult to implement from:

http://java.sun.com/j2se/1.4/docs/guide/rmi/spec/rmi-stubs24.html

I see two remaining problems:

The text is correct is referencing section 4.3.3 of The Java Virtual Machine Specification (first or second edition) for the definition of a "method descriptor". Unfortunately, the example descriptor string is incorrect-- the package qualification separator character should be '/' as in the VM spec, not '.', so the example string should be

myRemoteMethod(ILjava/lang/Object;Z)V

The text uses a piece of Java (or at least Java-like) code as a compact way of expressing how the bits of the SHA-1 message digest map to the bits of the "long" 64-bit method hash value:

     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;

The problem is that this code cannot be used verbatim in a Java problem to produce the correct result (assuming, as is stated in the preceding sentence of the text, that "sha" is of type "int[]"), because: Nothing causes the intermediate subexpressions to be of type "long", so they will all be treated as "int", and when the left operand of a shift operator is of type "int", only the lower five bits of the right operand are considered, so the bits from sha[1] will just get ORed into the lower 32-bits of the resulting value-- and when the final "int" result is converted to a "long" for the assignment, the upper 32 bits will either be all zeros or all ones depending on sign extension.

This code should be replaced with Java code that will actually make the correct computation when used literally (by casting subexpressions to "long" and masking to prevent sign extension as appropriate), or it should be replaced with a more abstract description or diagram of how the bits of the digest get mapped to the bits of the method hash value.