Stuart commented:
You can also optimize the test away (in the other direction) if it's known at compile time that the object *is* a string. Or is that unnecessary since String provides its own GetHashCode implementation that will be invokespecialed already since it's a final class (or whatever the CLR equivalent of final is)?
When you compile the Java code "foo".hashCode() it will be compiled as an invokevirtual java/lang/String/hashCode()I. When IK.VM.NET tries to compile this, it looks up the hashCode() method on String and finds that it should redirect to the static StringHelper.hashCode() method. So that's automatic. It is possible to create bytecode that does an invokevirtual java/lang/Object/hashCode() on a string reference, but Java compilers won't do this, so this is hardly worth optimizing.
11:49:57 AM  Comments
|
