I did some more looking into the problem where
an exception is raised in the reflect table
when a duplicate entry is found. I posted
a note to the java-linux list and everybody
seemed to think that the Java docs do not
*guarantee* that a unique id be returned
by the System.identityHashCode() method.
In JDK 1.1, the System.identityHashCode()
method would return a UID for a given
Java object (based on the pointer where
the memory was stored). That seems to have
been changed in JDK 1.2 for security reasons
(I guess they do not want anyone to know
the memory address of a Java object).
So this totally blows the reflect table
out of the water because there just does
not seem to be any way to get a UID for
a Java object (without keeping another
table of Object -> UID around, and that
would take up too much memory).
The reflect table currently works by
mapping a UID string to an internal rep.
ClassName.UID -> ReflectObject
ClassName.UID -> ReflectObject
I was thinking about it, and it seems
like the best way to fix this might
be to have a another "Conflict" table.
When the UID generated by concatenation
of the ClassName and System.identityHashCode()
conflicts, we map the class name to a Vector
of conflicting Java Objects.
ClassName.HASH.0 -> ReflectObject
ClassName.HASH.0 -> ReflectObject
ClassName.HASH.0 -> ReflectObject
(and in the case where ClassName.HASH.0
is already in the table, we would map
with something like)
ClassName.HASH.1 -> ReflectObject
In the case of a conflict, we could
look in a "Conflict" table, which
would map the conflicting ID prefix
to a vector of Objects that returned
the same HASH.
ClassName.HASH -> {obj1, obj264, obj27564}
Another approach could be to generate
a UID based on the HASH value of the
Object and the ReflectObject, something
like:
ClassName.ObjectHash.ReflectObjectHash -> ReflectObject
That is getting a little cute, but it
should work. The only catch is that
this could not be *guaranteed* to work,
it would just make a conflict extremely
unlikely because the hash values of both
objects would need to conflict.
Comments?
Mo DeJong
Red Hat Inc
----------------------------------------------------------------
The TclJava mailing list is sponsored by Scriptics Corporation.
To subscribe: send mail to [EMAIL PROTECTED]
with the word SUBSCRIBE as the subject.
To unsubscribe: send mail to [EMAIL PROTECTED]
with the word UNSUBSCRIBE as the subject.
To send to the list, send email to '[EMAIL PROTECTED]'.
An archive is available at http://www.mail-archive.com/tcljava@scriptics.com
