[jdom-interest] Why don't Comment, Element, Text, etc extend common jdom object?

[Bradley S. Huffman]

bob mcwhirter writes:

> I'm just guessing, as I'm not overly familiar with the FilterList
> stuff, but...
> 
> I imagine it should be somewhat possible to implement an Iterator
> that doesn't use the underlying collection's Iterator, but rather
> indices, to avoid concurrent modification exception.  In that case,
> there's only 1 iterator, which is completely under our control. 
> And for remove(), it delegates to detach(). 

Nope, concurrent modification is not a problem specific to JDOM but in the
way Iterator is defined. The problem lies in hasNext(), which when it returns
true means next() better return something. So in all collections if hasNext()
returns true for the last object in the collection and someone outside the
Iterator removes that object, next() fails eventhough hasNext() said it
wouldn't, breaking the Iterator contract.  This means for all collections
it's safest to have only one iterator doing modification. You can have
as many iterators as you like walking the collection, but more than one
doing modification or doing outside the iterator is dangerous.

DOM's tree walkers and node iterators avoid this problem by defining a special
value (null) to indicate end of traversal, so the only state they have to
maintain is the last object.  In hindsight it be nice if Java's Iterator
didn't have hasNext(), and had next() return null or a special object
(Iterator.END) to indicate the end of iteration, or even isDone() as in
Gamma.

Of course DOM's definitions aren't without their quirks. For example if you
remove from the document the last node returned from TreeWalker.nextNode(),
what is the walkers state?

Brad