[jdom-interest] JDOM and memory
jdom at tuis.net
Mon Jan 23 09:04:48 PST 2012
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.
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
>> 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
> Michael Kay
More information about the jdom-interest