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 [VOTE]: Should FetchPlan.getGroups return a copy or a reference?
Date Sun, 30 Jul 2006 19:58:28 GMT

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
         if (!setEquals(expectedGroups, groups)) {
                 "checkRemoveGroup(): wrong getGroups() " +
                     "after removeGroup.",
                     expectedGroups, groups);

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.



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!

View raw message