Also see the XMLC 2.2 Release Note, XMLC 2.2.1 Release Note, XMLC 2.2.2 Release Note, and XMLC 2.2.3 Release Note.
In LazyHTMLDocument, which is currently using a Hashtable, the createElement method will block on the _elementConstHTML.get() call, since hashtables are synchronized. Since the map is read-only after it is created, it should be slightly faster to use a HashMap, as long as one is careful not to access the map before it is finished being created. This patch should accomplish this, and offer at least a slight performance boost in multithreaded situations.
While investigating the speed of an application that uses XMLC 2.2.3, I (Pieter) encountered a serious performance bug in DOMFormatter. The DOMFormatter is used to write out the HTML (or XML) representation of a DOM tree. It uses a Writer onto a buffered output stream, but the Writer is itself not wrapped in a BufferedWriter. Without the BufferedWriter, every invocation of one of the Writer's write() methods causes the allocation of one object, presumably a byte array. Invoking the single-character-write method is one object worse, presumably it requires a character array. This includes the frequent invocations to the write methods to emit a '<', '&', and '>' characters. After some playing with a profiler, the memory consumption [of my application] was reduced by 50%, a significant part of which comes from this XMLC fix.
There were regressions in both HTMLFormatter and XMLFormatter from pretty printing added in XMLC 2.2.2 where the pretty printing code would affect the output (cause line breaks, etc...) even when it was not explicitly turned on. These have been fixed. There is still an issue with pretty printing, when enabled, creating truly pretty markup. However, this is not an urgent issue and will likely be addressed in 2.2.5.
Updated the Xmlc taskdef with descriptions of all possible attributes. Clarified a few existing descriptions.
Also made all boolean attributes (except for performexec which is a legacy attribute) take an actual Xmlc.BooleanAttribute and allowed BooleanAttribute to take "on/off" values. This makes sure that "yes/no", "on/off", and "true/false" all qualify as valid values for boolean attributes. Before, some attributes such as "force" took Strings and only accepted "true/false" as valid values which is inconsistent with other Ant tasks.