Hi Ben, So to ensure that I understand correctly you are proposing to move equals(), hashCode(), and the iteration from the SimpleFeatureTypeImpl up to a ComplexTypeImpl?
I think this makes sense. While I realize that the contract makes no promises about order, preserving the order in which a type was created with seems like a reasonable thing to do for the implementation. -Justin Ben Caradoc-Davies wrote: > Justin, > > I just found a case when we have to make your LinkedHashMap fix (or > other change to respect iteration order). In unit tests, if a complex > type is programmatically constructed, the XSD schema that is > automatically generated from it uses the property iteration order. This > is effectively random with the current HashMap implementation, making it > hard to predict what XML is encoded when a new property is added. > > As an alternative to LinkedHashMap, perhaps we should hang onto the > construction-time properties list so we can do iteration, equals, and > hashCode in one consistent change? Maybe pulling up the implementation I > put in SimpleFeatureTypeImpl? > > Opinions? > > Regards, > Ben. > > Ben Caradoc-Davies wrote: >> Justin, I have no objection. It should do no harm. However, note that: >> >> (1) order should never be important, except for special case >> subclasses such as SimpleFeatureTypeImpl (see below), and >> >> (2) LinkedHashMap conforms to the Map contract, which guarantees that >> order is *not* significant for equals/hashCode. Fixing iteration order >> does not fix this. >> >> I experimented with using LinkedHashMap in ComplexTypeImpl to fix >> SimpleFeatureTypeImpl iteration order, but when I realised it did not >> fix equals/hashCode, I made all my changes to SimpleFeatureTypeImpl. >> If you support my position, please join me in nagging Jody to get my >> patch accepted. Please take a look at it; the patch comes with unit >> tests for iteration order consistency: >> http://jira.codehaus.org/browse/GEOT-2338 >> >> More importantly, why do you want to change the order of properties? >> Do you have a non-simple use case in which they matter? If not, please >> consider my patch. >> >> Kind regards, >> Ben. >> >> >> Justin Deoliveira wrote: >>> Sorry, i did not mean tree map, just a map with predictable iteration >>> order. LinkedHashMap should do the trick. >>> >>> Justin Deoliveira wrote: >>>> Hi all, >>>> >>>> I think Ben may have brought this up recently, but looking at >>>> ComplexTypeImpl it seems property values are stored in a hash map, >>>> which totally throws away the order in which property descriptors >>>> are added to it. >>>> >>>> Any objection to making this a tree map as to maintain order? >> >> > > -- Justin Deoliveira OpenGeo - http://opengeo.org Enterprise support for open source geospatial. ------------------------------------------------------------------------------ Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H _______________________________________________ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
