[jdom-interest] Content as a Text Node (was JDOM JSR)

[Jason Hunter]

Brett McLaughlin wrote:
> 
> This is the second person in as many days that I consider to be reputable to
> bring up problems with the String content of an Element being stored as a
> String. I also know that Elliotte has the same concern, as do I.
> 
> I think the biggest issue with text nodes as non-Strings are the assumptions
> about its implementation; as in "It will be like DOM, which sucks in that
> area." I agree with this assessment, first. Second, I think we can implement
> this in a better way.
> 
> For example, I don't propose changing the signatures of getText(),
> getTextTrim(), or setText().
> 
> What I'd like to do is INTERNALLY store the Strings within a Text class (or
> StringContent, or whatever). We just return the equivalent of a getValue()
> on the node when the getText() style methods are invoked. However, we can
> return this class from a call to getMixedContent(), which makes perfect
> sense and helps some of the problems that Philip has come up with in adding
> decorators to allow traversal.

I have no fundamental objections to this approach.  It's something we
considered when Bob was looking for parentage for XPath, but we didn't
pursue it because he found alternate approaches.  

My two concerns with having a Text class are:

1) Addition of another class and the loss of one aspect of JDOM that has
always been very Java-friendly.  People "get it" when they hear "JDOM
uses String instead of some funky Text class".  That direct message is
lost with the addition of a Text class.

2) Memory consumption.  It depends on your JVM but I hear each object
adds about 40 bytes to the heap, and having the wrapper would be another
object per string.

It's probably worth it tho for the reasons stated earlier.  And we'll
get some goodness with CDATA being able to be a Text subclass.  (I think
it's probably better to keep a CDATA class rather than have a flag on
Text.)

Other thoughts?

-jh-