You could use visitor with instanceOf

interfaces:

interface Visitable {
  void accept(Object visitor);
}
interface AVisitor {
  void visitA(A a);
}
interface BVisitor {
  void visitB(B b);
}
interface CVisitor {
  void visitB(C c);
}

Visitables:

class C implements Visitable {
  public void accept(Object visitor) {
    if (visitor instanceof CVisitor) {
      ((BVisitor)vistor).visitC(this);
    }
  }
}

class B implements Visitable {
  public void accept(Object visitor) {
    if (visitor instanceof BVisitor) {
      ((BVisitor)vistor).visitB(this);
    }
  }
}

class A extends B implements Visitable {
  public void accept(Object visitor) {
    super.accept(visitor);
    if (visitor instanceof AVisitor) {
      ((AVisitor)vistor).visitA(this);
    }
  }
}

Visitors:

class PrintBs implements BVisitor {
  public void visitB(B b) {
    system.out.println(b);
  }
}

class PrintAs implements AVisitor {
  public void visitA(A a) {
    system.out.println(a);
  }
}

class PrintCs implements CVisitor {
  public void visitC(C c) {
    system.out.println(c);
  }
}
class PrintAsAndCs implements CVisitor, AVisitor{
  public void visitA(A a) {
    system.out.println(a);
  }
  public void visitC(C c) {
    system.out.println(c);
  }
}

each class knows only about its related interfaces, so adding new vistors nor visitables requires changing everything in that category (visitor/visitable) (for visitor, it does not require changing anything, for visitable it requires creating new visitor interface, but again, no changing of existing objects).

This way, there is no chain of instanceof tests and visitor for subset does not need to even know about types outside this subset.

Question is what to do with situation where A extends B (and B is Visitable too), in that case, you could just add super.accept(visitor) into accept (thus it would be short chain of instanceof-s, but onlu as long as hierarchy is deep, and it should not be too deep to matter, abd you don’t need to write it whole manually).

Well, yes, you could. Capture the commonalities of the many configuration elements by assigning roles to them. You may end up with instanceof, but not in a way that violates the DRY principle, but rather as a way around Java’s static typing.

class ConfigurationElementA implements IConfigurationElement, ICommittable {
}

class ConfigurationElementB implements IConfigurationElement, IVerifiable {
}

class Visitor {
    void accept(IConfigurationElement element) {
        if (element instanceof ICommittable) {
            // ...
        }

        // Note: not a chain of instanceofs.

        if (element instanceof IVerifiable) {
            // ...
        }
    }
}

In other words, you let the visitor accept configuration elements generically, and act on groups of implementations via roles. Note that you can go as specific as you need by modeling your configuration elements accordingly.

You may recognize here Martin Fowler’s RoleInterface pattern.

I can think of some potential solutions:

1. create a private method in the Visitor implementation, and have multiple visit methods in the Visitor implementation call that private method.

2. if the above is repeated in many places, you can consider creating an abstract class that implements Visitor, and redirects a subset of visit implementations to a common protected abstract method.

3. create multiple Visitor interfaces:

   interface AOrB extends IConfigurationElementVisitor {
       <Result> Result accept(AOrBVisitor<Result> visitor);
   
       interface AOrBVisitor<Result> {
           Result visit(A a);
           Result visit(B b);
       }
   }
   
   interface ThisCouldBeOfTypeB extends IConfigurationElementVisitor {
       <Result> Result accept(ThisCouldBeOfTypeBVisitor<Result> visitor);
   
       interface ThisCouldBeOfTypeBVisitor<Result> {
           Result visit(B b);
           Result visit(ThisCouldBeOfTypeB visitable);
       }
   }
   
   class A implements AOrB, ThisCouldBeOfTypeB {...}
   
   class B implements AOrB, ThisCouldBeOfTypeB {...}
   
   class C implements ThisCouldBeOfTypeB {...}
   

I think 3 is what you are looking for. it is 100% static polymorphism, and generates compiler warnings if a type isn’t handled. But the only disadvantage I can think of 3 is that maintaining the Visitable* implementations could become complex if there are a lot of different Visitable* interfaces.