As you know, in order to create a project processing process, you need to create a separate module, and already read in it. Is it possible to make this handler inside the main module of the project, so as not to create an additional module. if anything, I want to make a handler for finding annotated classes

application architecture

@SupportedSourceVersion(SourceVersion.RELEASE_17)
@SupportedAnnotationTypes("core.annotation.connect.Connect")
public class BuilderProcessor extends AbstractProcessor {

    @Override
    public boolean process(Set<? extends TypeElement> annotations, RoundEnvironment roundEnv) {
        for (TypeElement annotation : annotations) {
            for (Element element : roundEnv.getElementsAnnotatedWith(annotation)) {
                processingEnv.getMessager().printMessage(Kind.ERROR, "Class list: "   element);
            }
        }
        return true;
    }
}

CodePudding user response：

Sure, in the sense that once compiled the compiled module would be an annotation processor, and a thing you can run as a normal java app as well.

The problem is, now you have a chicken and egg problem: The annotation processor that this module defines cannot be used during compilation (annotation processors run as part of the compilation step) of itself - there's your chicken and egg problem.

Once you have a compiled version of your module and then rewrite a line or two, you could now 'recompile with itself as annotation processor', where the old compiled result is used as processor to compile a new version. But you now have a bootstrap issue: If ever you delete your last build binary you cannot possibly build your module anymore, because it requires an annotation processor you can't compile without travelling into the future.

As a consequence, the answer to your question is: "Technically yes, practically, no".

Unless, your intent is for the artefact you publish to be both a thing you can run as well as a thing you can use as an annotation processor, i.e. the annotation processor part is what you export to others, it's not what the project itself uses. In which case, sure, by all means, but it's possibly still possibly not a great idea; APs would be used in different places than the app 'take' of what your product can do, and tying up the dependencies of the one with the other is dubious.

An example 'one jar does everything' project is Project Lombok where a single jar is:

• An annotation processor (javac -cp lombok.jar codeToCompile.jar)
• An agent (it's how lombok works in ecj and eclipse)
• An app you can run which can do text processing (de-lombok source code, with java -jar lombok.jar delombok (args as if it was javac here).
• An installer, with a swing based userinterface (just double click the jar / java -jar lombok.jar).
• A module, with a module-info, that you can include on the module path; for module-based javac invocations where you then specify lombok as a module containing the processor instead of just sticking it on the classpath.