db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ilan Kirsh <ki...@objectdb.com>
Subject Re: [VOTE]: Should FetchPlan.getGroups return a copy or a reference?
Date Sun, 30 Jul 2006 21:27:17 GMT
Personally I prefer:
    [] 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.

But anything else is also acceptable, except:
    [ ] 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.
which makes things complicated for implementations (like ObjectDB) that do not use a standard
Java Collection to maintain the set of fetch groups internally.

Ilan

  ----- Original Message ----- 
  From: Craig L Russell 
  To: JDO Expert Group ; Apache JDO project 
  Sent: Sunday, July 30, 2006 9:58 PM
  Subject: [VOTE]: Should FetchPlan.getGroups return a copy or a reference?


  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!



Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message