Java idiom to define a call patttern matching a CFG

Assume a trivial XML-like document format with two terminal elements and and one recursively nestable element .... Assume the objective is to construct strings using the Java type system to allow new (syntactically valid) documents to be defined as cleanly as possible using Java. I'm envisioning a base class that can be hidden away in a class library - then for the definition of individual documents to be as intuitive and neat as possible.

Ignoring, for a moment, the recursively nestable element - this code represents one potentially viable approach:-

public class St开发者_StackOverflow社区aticDocument {
  private StringBuilder doc;
  protected StaticDocument() {}
  protected void nonNestedA() { doc.append("<A/>"); }
  protected void nonNestedB() { doc.append("<B/>"); }
  public String toString() { return doc.toString(); }
}

Using StaticDocument as a base class, it is possible to define documents using only Java to describe their abstract structure. An example document with sequential composition of A and B elements:-

public class ExampleDocument extends StaticDocument
{
  public ExampleDocument()
  {
    nonNestedA();
    nonNestedB();
    nonNestedA();
  }
}

Things get a bit more complicated when trying to extend this approach to embrace the recursively nestable element .... In C++ I might have used a protected inner-class of StaticDocument to define the Z element - then used the enclosing blocks in ExampleDocument to ensure every is matched with a - employing the RAII idiom/pattern. In C#, I could exploit the IDisposable interface and 'using' to a similar end. Another possibility is to pass an argument to a nestedZ method and have that argument encapsulate what to execute to generate the document surrounded by the Z element... but this is somewhat cumbersome - especially as Java(6) doesn't support either delegates or lambda expressions natively.

[Aside: I'm aware of tools like JaxB for XML... and that I can embed XML files in jars - but the question here is intended to capture a more involved objective - the XML just exhibits the same abstract structure.]

So.. finally... the question: Is there consensus among the Java community as to the best way to tackle problems like this? The objectives are to minimise extraneous intermediate objects during construction of documents - and for the construction of documents to be both as compact and as 'natural' (i.e. easily recognisable as matching the corresponding XML document) as possible.

I'd be interested to hear some expert opinions... and/or pointers to relevant articles.

You could use the builder design pattern and create nestable builders with a fluent interface that would represent your desired structure.

This examples uses them to create test data objects. But it applies to your scenario as well.

What about to just take your domain objects and serialize them to XML using XStream?