Direct renderring

Ordinary design

Using overriden Object#toString() is usual way to render object to string, finally it becomes byte stream in fact.

Necessity of intermediate string(s) for own renderring result costs very much, because String creation is expensive unexpectedly.

For example, assume that your object has hierarchical structure, and it needs rendered form of its children for own one. Processing flow around it is shown as below.

1. invokes toString() of its children

toString() of its children may often concatenate some string elements into result of it.

2. stores result into StringBuffer again and again
3. It begins own renderring, and stores result into same StringBuffer

It may also concatenate something.

4. creates String from StringBuffer as return value of own method
5. caller side of it may write result on specified java.io.Writer

In this case, toString() result of both children and your objects are intermediate string. Creation(including concatenation) of those strings costs very much, even though they are only part of final renderring result.

Decision in PageMixer

PageMixer defines render() method in both Token and Attribute.

At renderring time, they write string elements of rendered form on it directly.

This can reduce cost of intermediate strings creation. But it had to declare "java.io.IOException" throwing on consume(ConsumerContext, Token) and flush(ConsumerContext) of Consumer, because render method renderring on java.io.Writer is done as part of those invocation chains.

At least for me, it seems to decrease simpleness of Consumer derived classes definition, and to be important not for Consumer derived classes but for the class driving them.

Because of it, PageMixer provides SafeWriter to omit catching/throwing of java.io.IOException, and MixingIOException to catch it if you really want.