new DefaultMutableTreeNode(("Attribute (name = '" +
atts.getLocalName(i) + "', value = '" +
atts.getValue(i) +
"')").intern() );
Here you are also interning the attribute values, right?
Eh, no. The String "Attribute (name = ';name:', value = ';value:')" is interned.
But, as Glenn noticed, the attribute names can also be implemented with enumeration
There are no enumerations in pre 1.5 Java. What was meant was that strings denoting XSLFO property enumeration tokens can be interned as the set is of limited and more or less fixed size, while it is probably not prudent to intern the complete XML attribute value strings. For example: text-decoration="underline overline" (Yes, that's valid, provided "overline" is valid). The possibly interned strings are "text-decoration" (property name), "underline" and "overline" (enumeration tokens). Somewhere else, the user might have put text-decoration="overline underline" Granted, given that FO source ought to be XSLT or otherwise generated, this isn't very likely, but still.
Another issue is how the values are stored. For example, there are only 8 distinct TextDecoration objects. In 0.20.5, basically every Text node gets its own instance. The weird thing is, when I hacked the PropertyManager to look up the actual text decoration in an array of preinstantiated objects, FOP run slower and took more memory. Apparently something went wrong. If anybody is up there to get it right, please do. Same for some other objects, BorderAndPadding and especially FontInfo come to mind, although there is more variation.
J.Pietschmann
