Hi Jörg, On Nov 16, 2009, at 8:32 AM, Joerg von Frantzius wrote:
Hi Craig,you are absolutely right about the Query object being mutable, and thisconflicting with its use as a key in a HashMap. But telling from the general contracts of Map, equals() and hashCode(), I don't think that there exists a requirement for Map keys to be immutable.
Right. What I said is that for use as an element in a Set or as a key in a Map, the instance should return the identical hashCode and behave identically with respect to equals. So while the instance itself does not have to be immutable, hashCode and equals should act on immutable properties of the instance.
As I understand how these collections work, if you do change how hashCode and equals behave after construction, the instance should be removed from the collection and added again after the change is done. This is pretty tricky in terms of synchronization and order of operation.
There may also be other purposes for comparing Query objects using equals(), or Map implementations that don't require immutability of keys.I wouldn't ask if datanucleus wasn't already there halfway: datanucleus'JDO query object delegates to org.datanucleus.store.query.Query, which already correctly implements equals(), hashCode() and toString().
So does the query object change hashCode when the filter changes?
The only thing missing is the wrapper query object to also delegate these methods (I guess that was simply forgotten when that additional layer was introduced with JPOX implementing JPA). Just a small thing, I hope I'll find the time to fix it in datanucleusmyself. When that has happened, it could still be worth putting in the spec?
I don't yet understand the use case. Can you be specific as to what behavior you expect from a "proper implementation" of hashCode, equals, and toString, and how the implementation would be exploited by an application?
Regards, Craig
Regards, Jörg On 10/23/2009 06:57 PM, Craig L Russell wrote:Hi Jörg, On Oct 16, 2009, at 9:50 AM, Joerg von Frantzius wrote:Hi, it would be nice if the spec would mandate that implementations of javax.jdo.Query do correctly implement hashCode() and equals().As users execute mutator methods on queries, the string representationwould change. And for proper use in sets or map keys, hashCode and equals should be immutable after construction. So I don't see how we can mandate that hashCode and equals rely in any internal state.Alternatively, Query.toString() could be required to return thesingle-string representation of the query, or some dedicated method wasadded to provide it.Having the single-string version of a query is useful but adds implementation complexity. While there is a requirement for an implementation to parse a single string query into executable form, there's no current requirement to create the single string form from the internal form.This would make it easier to e.g. implement some custom cache for queryresults, or, more generally, it would make it easier to put Query objects as keys into Maps.It seems to me that if you want this functionality at the applicationframework layer, then the framework can mandate that the single stringform be used and at the time the query is created, the single string form be used as the key into a framework map. Regards, Craig____________________________________________________________________ artnology GmbH - Milastraße 4 - 10437 Berlin - Germany Geschäftsführer: Ekkehard Blome (CEO), Felix Kuschnick (CCO) Registergericht: Amtsgericht Berlin Charlottenburg HRB 76376 UST-Id. DE 217652550Craig L Russell Architect, Sun Java Enterprise System http://db.apache.org/jdo 408 276-5638 mailto:[email protected] P.S. A good JDO? O, Gasp!-- ____________________________________________________________________ artnology GmbH - Milastraße 4 - 10437 Berlin - Germany Geschäftsführer: Ekkehard Blome (CEO), Felix Kuschnick (CCO) Registergericht: Amtsgericht Berlin Charlottenburg HRB 76376 UST-Id. DE 217652550
Craig L Russell Architect, Sun Java Enterprise System http://db.apache.org/jdo 408 276-5638 mailto:[email protected] P.S. A good JDO? O, Gasp!
smime.p7s
Description: S/MIME cryptographic signature
