Re: JDOM and memory
Rolf Lear <[email protected]>
| Newsgroups | gmane.comp.java.jdom.general |
|---|---|
| Message-ID | <[email protected]> |
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 <[email protected]> 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 _______________________________________________ To control your jdom-interest membership: http://www.jdom.org/mailman/options/jdom-interest/[email protected]