Implemented in C ++, the object-oriented and the aspect-oriented characteristics of the VISITOR are assimilated, making it difficult to tell them apart. However, implemented in Java, which also does not support multi-methods, introduces a dilemma. The VISITOR patterns can be implemented almost exactly as in C ++, defining in each element class an accept() method, and in each VISITOR class multiple visit() methods (one per element class.) But, new core APIs permit a different implementation that is tailored for Java.
One adaptation to Java is to discard the original accept() methods and replace them with a general dispatching mechanism using Java's reflection. Another adaptation is to use Java's new event model as an alternative to writing visit() methods. Instead of sending a visitor to visit an element, the element is fired to the visitor as an event. Visitors may then be wrapped as JavaBeans and weaved in different ways using standard builder tools.
A visitor may register as an event listener with (possibly many) other visitors, and send events to (possibly many) other visitors. An arbitrary graph of event passing may be constructed, representing a complex visitor composition (improving the inheritance-genericity model proposed in [5]), while keeping a clean separation between reflective, traversal and behavioral visitors. With Visitor Beans it is possible to extend class hierarchies that never anticipated extension. Join points, like the accept() and visit() methods, no longer create undesired coupling between aspects. Further implementation details and lessons learned in aspect-oriented programming are reported in [6].