| 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! |
smime.p7s
Description: S/MIME cryptographic signature
