Memory leakage. There are a large quantity of leaked symbols. By that, I mean that of those symbols that should be dropped after the final parse tree is assembled, many are still pointed to somewhere in the tree. Because of the doubly-linked nature of the tree, if any client holds onto just one symbol of the tree, most of the parse tree will stick around. Hopefully we can clean that up in the future, but it's not real high priority right now.
Infix operators. Infix precedence is unavailable at the recognition level (if it was, it would cause 97.5% of the generated expressions to be useless as opposed to just 80%). The recognizer handles this by creating a parent InfixExpressionSymbol and creating more InfixExpressionSymbols as it continues to encounter more infix operators. As these infix symbols are created, they're pushed onto a InfixExpressionSymbol.InfixPrecedenceStack object kept by the parent infix symbol. The stack object determines the correct order of execution and rearranges the tree accordingly.
Postfix operators and primary selectors. Given a series of such operators, the operators are executed from left to right which is opposite the order they are added to the parse tre. Similar to the infix operator, a sequence of such operators will have a parent symbol. The PostfixExpressionSymbol and PrimaryExpressionSymbol both maintain stacks and after the sequence of operators has concluded, it rearranges the tree accordingly.
Typecasts. Now, the way the parse tree handles typecasts isn't real pretty. There is a constructor TypeSymbol( ExpressionSymbol, ReadTextBuffer ) that takes care of this conversion. Simply put, it ain't real pretty. A SYNTAX_EXP_INNER is considered to be a typecast if its data value is JavaTokens.TK_LPAREN.