[jdom-interest] New realease, Text class... Arghh

[Alex Rosen]

True, the Text changes are not backwards compatible. When we discussed this
at the time, we felt that it was a worthwhile tradeoff - you only get one
chance (ie 1.0) to do things right, and this *is* a beta. There were a lot
of very positive sentiment at the time, and much less negative sentiment.
The meat of the discussion is here, but there's a lot more before and after
this too.

http://www.servlets.com/archive/servlet/BrowseList?listName=jdom-interest&by
=subject&from=2627

I'm certainly sympathetic to your complaints. But, we can't please both the
people that want it stable, and the people that want it right. And we can't
keep changing our minds back and forth...

Your other points I pretty much all agree with. They are all optimizations
however - the Text vs. String argument is the only one that we *must*
resolve before 1.0.

When we first talked about Text, we said that we'd start with something that
worked, and then do some performance analysis to figure out the best
implementation. I agree that using StringBuffer in SAXBuilder, and String in
Text, is likely to be the best way to go. Jason/Brett, do you have Phil's
patch?

I agree that it would be a cleaner (and less error-prone) implementation to
have the main Element backing lists be the "gatekeepers", to avoid duplicate
code, and so getContent() and getAttributes() don't create any objects.
(This "gatekeeping" involves checking that e.g. you don't add an Attribute
or an Integer to the getContents() list, and that the item's parent is set
and unset when the item is added or removed.) Then only getChildren() needs
to do any "filtering" (i.e. only letting the Elements show through). It's
still not 100% clean, however - does the getChildren() list still want to
prevent Comments from being added? Does getChildren(String) want to check
the new Element's tag name? So the filtering list probably wants to do a
little bit of gatekeeping too.

I'm not sure I get your third point about Filter iterators. How will they
help?

Alex Rosen
SilverStream Software

> -----Original Message-----
> From: jdom-interest-admin at jdom.org
> [mailto:jdom-interest-admin at jdom.org]On Behalf Of phil at triloggroup.com
> Sent: Wednesday, January 09, 2002 10:39 AM
> To: jdom-interest at jdom.org
> Subject: [jdom-interest] New realease, Text class... Arghh
>
>
> As the Text class does not inherit from a common base class
> with the other elements, I cannot find any reason to get it.
> Moreover, we currently have lot of code that checks for
> explicit String when browsing an element content, and this is
> *not* compatible. Do you really
>
> Moreover, it really seems that it is not designed for performance:
> => I agree with A Rosen thread (from last may) who said that
> using a StringBuffer is not the good thing to do.
> First, it is really more frequent to browse a XML document
> (query, xpath evaluation...) than appending data to an
> existing text. And the toString() method always creates a new Object!
> Secundo, when do we have to append string to existing one?
> Mainly in the SAXBuilder, because the parser can split a
> string in different character arrays. I circumvent that
> easily (I uploaded a change to the JDOM authors) by simply
> adding a StringBuffer in the SAXBuilder class itself. That
> StringBuffer was allocated only once and shared by all the
> text instances. This was really optimized (OptimizeIt
> reported a three times performance gain!).
> => It creates an object wrapper for every strings, thus
> having an unwanted overhead and a stress for the garbage
> collector.
>
> Now, let's go to the FilteredList.
> Ok, that better than the awful PartialList. But they are
> still pitfalls.
> 1. We need to store items not in an ArrayList, but in a List
> inherited from ArrayList, mainly to automatically manage
> the parent/child relationship. For example, there's currently
> a bug in the Element.setText() method, because it does a
> content.clear() that does'nt reset the parent property of objects.
> 2. The getContent() is still unoptimized, while used very
> often. It can directly return the 'content' list if
> implemented as defined in 1.
> 3. Having direct iterators that deals with the actual list
> using the Filter class will also performs better. It will be
> great to have a getChildrenIterator(Filter) method.
> 4. The Filter class design mix both the filter capability
> with other capabilities. Humm...
>
> I'm negative because I'm really both disapointed and upset
> with that new release.
> I want to be positive by saying that I really want to
> actively participate to that project. I already send proposal to
> both Brett & Jason but never got answers
>
> Phil.
> Trilog Group Software