We have multiple visitors implemented and in use currently in graphql-java:

Current State

DocumentVisitor implemented by RulesVisitor and TraversalContext is a visitor used by LanguageTraversal to validate requests.

TraversalContext actually tracks the current schema informations: what is the current output type etc.
RulesVisitor just delegates to every rule for checking a specific Node with the help of the TraversalContext.

We have the most general Traverser and TraverserVisitor which actually have not dependency on any graphql specific thing: they enable general breadthFirst and depthFirst tree traversal.

NodeVisitor which is used by NodeTraverser enables Ast Node traversal. (Powered by the general Traverser)

QueryTraversal which is build on top of NodeVisitor allows traversing a query while tracking the schema informations. (This means you get the actual type informations for every field visited)
QueryTraversalContext tracks the current type informations.

GraphQLTypeVisitor which is used by TypeTraverser enables GraphQLSchema traversal. (Powered by the general Traverser)

Thoughts

QueryTraversal should probably be combined with the whole Rules world for validation. (For example QueryTraversalContext is basically the same as TraversalContext) The challenge might be that QueryTraversal can assume a valid schema, but Rules can not assume anything.

With the goal to make all Ast Nodes really immutable we need a good way to modify a Document. This means probably a Visitor combined with some transformation. See also #1148

We want to have more powerful validation utils (probably based on some SDL directives): See #1211.

This could be implemented in some form of a SDL Reducer which results in Query validator. Currently we have query validators implemented in the form of Instrumentations (MaxQueryDepth... and MaxQueryComplexity...)