The Result implementations such as JavaDomainResult have extreme
behavior
since they recurse all the way down to produce the result and then,
only then process the method call. Instead, what we want, most of the
time,
is to process the method call immediately, by the wrapped object.
The class JavaDomainWrap does just that, but what it is useless.
We need structure specific implementations that do something interesting
The recusion food is an object passed down the eval() hierarchy to bound
the total computation time and perhaps pass/accumulate other
calculations
try this design pattern. Use the TypeResult class as a base class for
the 
operation specific implementations of the interface Type, so that all
the 
methods of the interface have a valid, albeit inefficient,
implementation.
The operation specific subclass, such as CharSequenceConcat, override
certain operations
implemented the class, but there is a problem with initializing the base
class
attempting to construct the class from a JavaArrow, but there is 
a problem with the capture-? wildcard
made CharSequenceResult parametric in the operand variable to resolve
the capture problem. All compile errors are fixed
overridden CharSequence.length (returns always 0 though), to illustrate
how a String method can be replaced with one that takes advantage of the
particular representation of String employed the current class.
This implementation of length AVOIDS the default behavior of the 
CharSequenceResult, which would expand the whole string just to calcuate
the length!