Stuart commented:
What do you do if you have a Java program that depends on String.hashCode() doing exactly what Java defines it to do (ie, produce consistent output with other VMs) rather than what .NET defines String.GetHashCode() to do? I encountered this in my own code so in theory I can implement (or steal from ClassPath) an implementation of String.hashCode() and use that, but the problem could come up in other scenarios. It's an interesting one, don't you think? :)
I haven't gotten around to implementing it, but the idea is that all virtual calls to Object.toString() are changed to:
if(o instanceof String) return StringHelper.hashCode(o);
else return Object.GetHashCode();
One reason I haven't done this yet, is because I think it is totally brain damaged that Sun actually specified the hashcode algorithm for String (and in JLS 1.0 they specified a broken algorithm, which JDK 1.0 didn't implement), another reason is that I haven't figured out how to build this generically (specified in the map.xml file, instead of hardcoded in the VM).
A similar issue also occurs with Object.toString(). Nonvirtual calls to Object.toString() should be redirected to a helper function that returns:
getClass().getName() + "@" + Integer.toHexString(hashCode())
This isn't really a problem (if you accept the fact that non-Java classes return something different for toString(), which I do), but for arrays it does pose a problem. For arrays to return the proper string when toString() is called on them (virtually through an object reference), all virtual calls to Object.toString() need to be treated like hashCode() above.
btw, how come your example isn't "import System.Reflection"? Does netexp auto-lowercase all namespace names?
At the moment it does. Not because this is the Java convention, but because Java cannot really deal with a namespace System (because of the class java.lang.System).
That seems risky if (as I believe, but don't know for sure) it's possible to have two distinct .NET namespaces with names differing only by case...
This is true, but in practice it seems unlikely you'll ever encounter a problem with this, but the case conversion will definitely be optional in the future.
9:13:57 AM  Comments
|
