| erik@jpox.org 2005-12-30, 7:45 am |
| Quoting Craig L Russell <Craig.Russell@Sun.COM>:
> Hi Erik,
>
> For the record, the quoted lines are not mine. Credit where credit is
> due. The quoted lines are David Bullock's.
>
Oh, my apologies. Too much wine these days.
> More comments below.
>
They answer my question. Thanks.
> On Dec 29, 2005, at 3:41 PM, erik@jpox.org wrote:
>
>
> I guess not.
>
>
> I don't follow. Sidebar: the quoted section is from javadoc for
> java.util.Collection, which for the purposes of this discussion I've
> copied below. A correct implementation of java.util.List (or
> java.util.Collection, or any of the other supported collection types)
> will respond appropriately to all the methods in the interface. Some
> of the methods can be implemented to avoid loading the elements of
> the collection by translating the methods into equivalent back end
> datastore calls. If an implementation doesn't want to bother with the
> details, then it has the ability to transparently instantiate the
> collection and then run the user's method.
>
> This is fine. This is discussed in 5.4:
> Applications should implement equals for persistence-capable classes
> differently from Object’s default equals implementation, which simply
> uses the Java VM object identity. This is because the JVM object
> identity of a persistent instance cannot be guaranteed between
> PersistenceManagers and across space and time, except in very
> specific cases noted below.
> Additionally, if persistence instances are stored in the datastore
> and are queried using the == query operator, or are referred to by a
> persistent collection that enforces equality (Set, Map) then the
> implementation of equals should exactly match the JDO implementation
> of equality, using the primary key or ObjectId as the key. This
> policy is not enforced, but if it is not correctly implemented,
> semantics of standard collections and JDO collections may differ.
>
> Craig
>
> java.util.Collections
> any methods in Collections Framework interfaces are defined in terms
> of the equals method. For example, the specification for the contains
> (Object o) method says: "returns true if and only if this collection
> contains at least one element e such that (o==null ? e==null :
> o.equals(e))." This specification should not be construed to imply
> that invoking Collection.contains with a non-null argument o will
> cause o.equals(e) to be invoked for any element e. Implementations
> are free to implement optimizations whereby the equals invocation is
> avoided, for example, by first comparing the hash codes of the two
> elements. (The Object.hashCode() specification guarantees that two
> objects with unequal hash codes cannot be equal.) More generally,
> implementations of the various Collections Framework interfaces are
> free to take advantage of the specified behavior of underlying Object
> methods wherever the implementor deems it appropriate.
>
> Craig Russell
> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
> 408 276-5638 mailto:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
>
>
|