I've now pulled the recursion out of the Canonicalizer. Outside of samples, (hmm, should probably add a non-recursive sample as well) there are now by my count three significant places that use recursion when walking a tree:

1. The Serializer, which I'm pretty sure I'm not going to fix because the changes to the API and consequent limited functionality would be too severe. The Canonicalizer's API is not nearly as rich so I was able to fix it there. Possibly I'll add a NonRecursiveSerializer to the samples package.

2. XInclude, whose code is so yucky and nasty I don't want to touch it, at least not yet. I'll probably throw a lot of this away and rewrite the internals at some point in the future. When I do that, I may make it non-recursive, but not just yet.

3. The Element copy constructor, and by extension Element's copy method. This is the one I'm on the fence about. It's not that much harder to make it non-recursive. The problem is that if I do so, then descendant elements can lose their subclasses since the copies will be created with the Element constructor and copy() method rather than the Element subclass copy constructor and copy method. This could be fixed but only by adding an additional protected method to the Element API that creates an empty element of the right subclass which copy could then call. That's a fairly large wart in the API just to avoid an uncommon problem that can be solved by setting a larger stack size when invoking the Java virtual machine. What do people think?