Re: RefAssociation.refAllLinks() really live in MDR ?

On Mon, Jul 01, 2002 at 04:19:12PM +0000, Tomas Zezula wrote:
>     you are right the returned collection should be live immutable 
> collection, but it is
> not-live immutable Collection. This is a bug in the MDR implementation.

Thanks for the info. I think there are other similar bugs, e.g.:

Given:
  A attribute of CollectionType of class C
  obj instance of C
  MyCollection extends Collection

The following code will result in undefined state:

  MyCollection coll = createMyCollection();
  obj.setA(coll);
  coll.changeMyCollection();

IMHO in the MDR implementation it is not defined, if the state of
`coll' after `createMyCollection()' or after
`coll.changeMyCollection()' is written to disk. This depends on if
`obj' is marked as having been changed. E.g. if

  obj.setB(bValue);

is called after the code given above, then the new state of `coll'
will be saved. If the repository is shut down after
`coll.changeMyCollection()' the old state of `coll' will be saved.

Correct assessment ?

I currently assume that you at the MDR developer team know about such
shortcomings and am looking for a list of all of them. Additionally I
want to offer resources to fix them ASAP. On the other hand it might
well be that you are not aware of such problems, then I can prepare a
list of what I would like to fix (and enhance ;-) and in what
order. So please tell me if problems like the one reported in the
preceding mail and in this one are already known.

For me it's not a problem that MDR has these problem, but I would like
to start the process to fix them ASAP.

For the problem with attributes of CollectionType see although the
thread
http://mdr.netbeans.org/servlets/BrowseList?listName=dev&by=thread&from=12563
where mere mortals like Brian and me have problems to understand JMI
semantics of CollectionType attributes.

-- 
Holger Krug
[email protected]