http://gwt-code-reviews.appspot.com/1395804/diff/11/user/test/com/google/gwt/user/client/rpc/TestSetFactory.java File user/test/com/google/gwt/user/client/rpc/TestSetFactory.java (right):
http://gwt-code-reviews.appspot.com/1395804/diff/11/user/test/com/google/gwt/user/client/rpc/TestSetFactory.java#newcode508 user/test/com/google/gwt/user/client/rpc/TestSetFactory.java:508: return map;
You've caused me to think about it some more (always a good thing).
Testing
this, and even defining the right behavior, is non-trivial. Say that
on the
client I add two objects that are reference-distinct but
equals-identical. The
IdentityHashMap should store those separately. When serialized, it
seems that
the server should reconstruct an identity map with two distinct
entries, and be
able to send it back. We're not testing this at all, so I'll make an
attempt to
generate such a case.
I can see the value, but for the purposes of landing this change, the enum thing would probably be enough, we don't actually need to exhaustively test IdentityHashMap.. just that it serializes ok.
As far as I can tell, the case you are referring to occurs when you
place some
object in an IdentityHashMap, serialize and get back the map. The
element in the
deserialized map should be reference equal to the original element. I
don't see
how we can guarantee such semantics.
It doesn't.. we don't preserve reference identity on round-tripped objects, unless there's a custom serializer to enforce singleton semantics. That's why I suggested using enums, since enums DO enforce singleton.
We're probably getting to the heart of why nobody ever hit this bug in
the first
place. It's not clear why you would ever want to serialize an
IdentityHashMap. http://gwt-code-reviews.appspot.com/1395804/ -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
