db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig L Russell <Craig.Russ...@Sun.COM>
Subject Re: [VOTE]: Should FetchPlan.getGroups return a copy or a reference?
Date Mon, 31 Jul 2006 22:23:03 GMT
> [+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:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
>

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!


Mime
View raw message