Hi Paul... I find that hard to believe as in my experience gwt deserialises complete objects further down the graph before returning instances to objects higher up in the graph.
You can also set breakpoints in the map/set custom serializers and watch the completeness of your objects before they are put or added to the map/set...? Capture the generated source for the serializers fir your classes and take a look at the source. I'm sure you will find complete instances are always returned ? Have you tried serializing / deserislizing the same graph using normal java toverify your "problem" classes. Have you tried recreating the same objects on the client with the same values and adding them to a set or map and see if they work correctly ? On 17/04/2009, at 6:05 PM, Paul Robinson <[email protected]> wrote: > Cycles are handled properly - the problem comes with calling methods > on partially formed objects during deserialization. It doesn't > matter how you implement equals or hashCode if those methods are > called before any data is deserialized onto your objects. You just > need a suitable object graph for this to show itself. > > On Fri, Apr 17, 2009 at 1:01 AM, Miroslav Pokorny <[email protected] > > wrote: > > If one were to serialize the entries rather than recreating the map > via put alot of other things would need to be changed. > > For one the calculation of hashcodes in emulated jre would need to > match those on the server otherwise look ups by string in a hashmap > sent over the wire would never work. Which jre would one base > calculation a on - I say this because wire formsts can and do chsnge - > which is why serialUID exists etc . We don't need to introduce that > into gwt serialization and make things more complicated and bloated. > > Unfornately javascript is not the fastest ultimately to improve > serialization performance in javascript one needs to to sensible > things like tailoring what gets marshalled. The browser has limits and > one needs to do the hard work and change accordingly... > > Um peetty sure gwt handles cycles properly without problems - perhaps > your objects in the map / set are changing in some way or your equals/ > hashcode is broken. > > Regarding your problem gave you confirmed serializi g the same > instances to bytes and back in real java??? > > Hth. > > On 17/04/2009, at 2:04 AM, Paul Robinson <[email protected]> wrote: > > > > > I've found what I think is a bug in the RPC deserialization code for > > handling HashSet and HashMap in GWT 1.5.3 (though I believe it > applies > > to trunk as well). The symptoms I had initially were that I sent an > > object tree to the client, and a HashSet that had 2 elements on the > > server only had 1 by the time it got to the client. > > > > When deserializing, an instance is created, stored in a map so > > repeated > > references can use the same instance, and then the fields of the > > instance are deserialized. If you have an object tree where A > > contains > > a reference to something that has a reference to B, and B contains > > something that has a reference to a HashSet that contains both A and > > B, > > then when deserializing the set, both A and B may only be partially > > constructed (depending on the order in which the fields and > instances > > are deserialized). This would be ok except that HashSet > > deserialization > > is done by Collection_CustomFieldSerializerBase which ends up > calling > > HashSet.add(Object) to reconstitute the set, and that in turn calls > > equals() and hashCode() on the object being added in. > > > > This gives rise to two possible errors: > > (1) Depending on how the equals() method on A and B is implemented > and > > on the order in which the fields are deserialized, A.equals(B) may > be > > true at the time that A and B are added to the set. However, > > A.equals(B) > > could later evaluate to false once the whole deserialization has > > completed. This would mean the set is missing one of the objects, > > since > > HashSet.add() thinks they are the same. > > > > (2) When adding an object to a HashSet or HashMap during > > deserialization, if the object being added is partially constructed, > > then the hashCode() method may return a different value as it is > added > > to the set from what it does when deserialization is complete. This > > could lead to occasional data-driven bugs that are very hard to > > track down. > > > > Have I got this right? Is this a bug (or perhaps a known > limitation)? > > > > In my case, I have been able to work around this by creating a > custom > > field serializer that chooses the order in which fields are written > > out > > so that partially constructed objects will still behave properly > in a > > HashSet/HashMap. > > > > Paul > > > > > > > > > > > > > --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
