[jdom-interest] Collections.sort and multiple parent-child re lationships

[Stephan Trebels]

Before I respond here, let's get one preamble done:

I don't think this is going to be useful for a big amount of cases.
There are special cases, where this can be enourmously useful, but
that's just special cases.

My main point is just, that I do not understand, which is the
reasoning behind the exception, as it does not protect against a real
problem.

On Wed, Sep 18, 2002 at 05:11:22PM -0700, Harry Evans wrote:
> > JDOMFeatures.setFeature(JDOMFeatures.WE_WANT_NO_DUPLICATE_CHIL
> > DREN, true);
> 
> I do not understand in what cases you would ever want such a feature to be
> false.

If this is the XML
<Parent> <Child id="1"/> <Child id="2"/> <Child id="1"/> </Parent>

Then there are two JDOM trees, that can represent this, Parent's list
of Child elements will contain three entries, where entries 0 and 2
can be the same instance or effectively clones.  XMLOutputter will do
the right thing.

This is useful for indicators, e.g. if you generate a sequence of events
from a database, imagine a list of 200000 entries...
<BitSequence> <On/> <Off/> <On/> <Off/> </BitSequence> 
Then JDOM wouldn't care whether all Ons are the same object or all
clones, while memory savings would be big.  (Yes, this is a constructed 
example, and no, I would never represent this in JDOM myself).


So in summary:

0. AFAIK, it does not break anything.  An exception should not be
   thrown, if we don't like something, but if something happens, that
   would cause problems.

1. For using JDK's Collections.sort, it needs to be there
   or we have to add Element.sortChildren() ... which is 
   essentially duplicated code.

2. Sometimes, when building a JDOM tree, we might know already, 
   that a whole subtree needs to be replicated, memory might be saved
   for internal representation.

> Perhaps a better idea would be to implement a solution that allows an
> Element to be added back to the list without checking its parent association
> in the case of List sorts.  In the case of the standard sorting algorithms,
> this would cause any element in the original list to end up there only once.
> I am not quite sure about how this would be implemented in the current
> scheme of things, but that would allow the sort to occurr while not throwing
> the exception.  Might be a special case, but it seems to be one that a lot
> of people are hitting.
> 
> I guess something like what Jason Robertson suggested would be what I am
> describing, though it would be nice if it could be done in such a way that
> the standard java.util sort methods could be used.

What was described was essentially

void Element.sortChildren() {
   relaxChildCondition();
   Collections.sort(getChildren());
   enforceChildCondition();
}

void Element.sortChildren(Comparator comparator) {
   relaxChildCondition();
   Collections.sort(getChildren(), comparator);
   enforceChildCondition();
}

Stephan
-- 
[------------ Stephan Trebels <stephan at ncube.de>, Consultant -----------]
company: nCUBE Deutschland GmbH, Hanauer Str. 56, 80992 Munich, Germany
phone: cell:+49 172 8433111  office:+49 89 149893 0  fax:+49 89 149893 50