[jdom-interest] JDOM and memory

[Rolf Lear]

Heh... you are right.

Element should not be List<Content>, and the getContent() method can
create a dynamic implementation as needed. That's the solution... Element
already has rules about synchronization so multiple 'active' dynamic
instances should not be a problem....

Thanks. I will play with that concept.

Rolf

On Mon, 23 Jan 2012 16:59:35 +0000, Michael Kay <mike at saxonica.com> wrote:
> On 23/01/2012 16:28, Rolf Lear wrote:
>> Hi all.
>>
>> I have started on this memory optimization, and it is still in early
>> stages. There is one API issue though:
>>
>> The Element API has the two methods:
>>
>> addContent(Content node)
>> addContent(Collection<? extends Content>  newContent)
>>
>> if I make Element implement List<Content>  (which is what this
>> memory-change will do), then the above two methods become ambiguous
>> because
>> Element will be both Content and List<Content>
> And that suggests to me that it is a bad idea.
> 
> The class hierarchy should reflect "is-a" relationships, it shouldn't be

> designed to tweak performance. It's not true that an Element and its 
> contents are the same thing, therefore it's wrong to treat them as being

> the same object. It will only lead to confusion.
> 
> You can achieve the memory saving by having Element.getChildren() create

> the returned List object dynamically (it doesn't need to copy any data 
> to achieve this).
> 
>  > The logical thing to do would be to deprecate addContent(Collection)
> 
> I don't think that solves the problem. There will be cases where 
> existing code fixes up to the wrong method, and ends up adding the 
> children of an element to a new parent rather than adding the element 
> itself.
> 
> Michael Kay
> Saxonica