--On Monday, July 03, 2000 4:24 PM -0700 Mo DeJong <[EMAIL PROTECTED]>
wrote:
> Exception in thread "main" tcl.lang.TclRuntimeError:
>
> (find) table entry "SomeObject.1512497281" mapped to an invalid
> entry,
I'm not familiar with the Jacl code base, but this error does not jibe with
my own experiences with this method under heavy load situations. Is it
possible that this is a bug in the Jacl engine? A real easy test would be
take the two object which are supposedly using the same identity hash and
test if the two objects are indeed identical.
Other items worth noting:
1) By the strictest of interpretations of the specifications of the
specifications, it is in fact legal for two different objects to return the
same value for System.identityHashCode() so long as you don't test the
values at the same time.
2) If the previous object has been garbage collected, this in theory frees
up the hash code for another object to use. Make sure that you really have
two objects and this is not just a left over value from an already GC'd
object.
My suspicion is that you are discovering that the JDK 1.2+ VM's move
objects around in memory when they GC. This potentially results in
different return values for System.indentityHashCode() for the same object
before and after a GC.
So the assertion that:
static MyClass {
private static MyClass firstInstance = new MyClass();
private static int fiHashCode = System.identityHashCode(firstInstance);
public bool assert() {
if (this == firstInstance)
return true;
else
return fiHashCode != (System.identityHashCode(this));
}
}
MyClass.assert() will never return false is not true.
--Chris
----------------------------------------------------------------------
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
