Is there a reason why this generator would receive the fileDescriptors through the generateValidatorFiles() method instead of the constructor? I'm fine with your approach, I'm just wondering if all generators should follow the same design for consistency and maintainability. Thoughts?

When I look at all this code in GtfsAnnotationProcessor, there seems to be a recurring pattern of:

for (JavaFile javaFile : new SomeGenerator(fileDescriptors).generateValidatorFiles()) {
      writeJavaFile(javaFile);
}

I think a lot of this repeated code could be better simplified with a new interface:

public interface ValidatorGeneratorForFiles {
  Iterable<JavaFile> generateValidatorsForFiles(List<GtfsFileDescriptor> fileDescriptors);
}

and then code like:

ImmutableList<ValidatorGeneratorForFiles> generators = ImmutableList.of(new XYZGenerator(), ...);
for (ValidatorGeneratorForFiles generator : generators) {
  for (JavaFile javaFile : generator.generateValidatorFiles(fileDescriptors)) {
    writeJavaFile(javaFile);
  }
}

In that world, it's convenient to construct the generators separately from the file descriptors they'll ultimately be operating on.

Admittedly, that's the theory anyway. Looking at the existing generators, I acknowledge they all currently accept the descriptors via constructors. There's an argument that matches the "command" pattern, where each object encapsulates all the data it needs to executue.

But I couldn't help but look at that code and think it needed a refactor. For example, why do all the generators include their output package as a repeatedly defined static param. Stuff like that should be consolidated as well.

I agree with you. I think we can keep your code as is in that context. I opened an issue and linked this comment to it.