Re: [VOTE]: Should FetchPlan.getGroups return a copy or a reference?

[Craig L Russell]

[+1 ] Require the jdo implementation to return a read-only copy of the underlying Set of groups as it exists at the time of the call. I'm persuaded by the argument that an implementation might not use an underlying Set as the implementation artifact. If this is the case, the implementation must create a class that implements Set that tracks changes made to the underlying data structure. So I think that requiring a "live" Set object on the interface would inappropriately conflate implementation and behavior. For implementations for which the underlying implementation is a Set, the implementation of this change is trivial. Instead of "return Collections.unmodifiableSet(groups);" it would be "return Collections.unmodifiableSet(new HashSet(groups));" Craig On Jul 30, 2006, at 12:58 PM, Craig L Russell wrote: Javadogs, During testing of FetchPlan, Ilan Kirsh discovered that the jdo specification doesn't specify whether getGroups returns a read-only copy of the set of fetch groups or can return a read-only reference to the actual set of fetch groups. [The specification does require returning a read-only Set.] The TCK as it was written requires a read-only reference, not a copy. This can result in non-portable behavior, if the application code expects a "live" reference instead of a copy. The TCK currently has the following code, which depends on the jdo implementation returning a "live" reference:     public void checkRemoveGroup() {         Set expectedGroups = new HashSet();         FetchPlan fp = getPM().getFetchPlan();         Collection groups = fp.getGroups(); // this assumes that groups is updated by the following line         fp.removeGroup("default");         if (!setEquals(expectedGroups, groups)) {             failCompare(                 "checkRemoveGroup(): wrong getGroups() " +                     "after removeGroup.",                     expectedGroups, groups);         }         cleanupPM();     } Please advise: [ ] Leave it alone.  [ ] Update the specification to note that getGroups returns a Set that might change if the underlying Set of groups changes (via addGroup, addGroups, removeGroup, removeGroups, clearGroups). [ ] Require the jdo implementation to return a read-only reference to the underlying implementation that will continue to track modifications made to the Set of groups. [ ] Require the jdo implementation to return a read-only copy of the underlying Set of groups as it exists at the time of the call. Thanks, Craig Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp!

smime.p7s
Description: S/MIME cryptographic signature