java.lang.IllegalArgumentException: The GraalVmProcessor annotation processor is missing the required log4j.graalvm.groupId and log4j.graalvm.artifactId options

[ratoaq2]

Hi all,

I have a java 21 maven project which uses eclipse compiler org.codehaus.plexus:plexus-compiler-eclipse:2.15.0 and has a log4j plugin using a Log4j2Plugins.dat file and configured the compiler with:

<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-compiler-plugin</artifactId>
  <executions>
    <execution>
      <id>generate-log4j-plugin-descriptor</id>
      <goals>
        <goal>compile</goal>
      </goals>
      <phase>process-classes</phase>
      <configuration>
        <proc>only</proc>
        <annotationProcessorPaths>
          <path>
            <groupId>org.apache.logging.log4j</groupId>
            <artifactId>log4j-core</artifactId>
          </path>
        </annotationProcessorPaths>
        <annotationProcessors>
          <processor>org.apache.logging.log4j.core.config.plugins.processor.PluginProcessor</processor>
        </annotationProcessors>
      </configuration>
    </execution>
  </executions>
</plugin>

After upgrading from 2.24.3 to 2.25.0 now my compilation is failing with:

19:43:54  [INFO] --- compiler:3.14.0:compile (default-compile) @ common ---
19:43:55  [INFO] Recompiling the module because of changed source code.
19:43:55  [INFO] Compiling with eclipse [debug deprecation parameters target 21] to target/classes
19:43:55  [INFO] -------------------------------------------------------------
19:43:55  [ERROR] COMPILATION ERROR : 
19:43:55  [INFO] -------------------------------------------------------------
19:43:55  [ERROR] /redacted/XXXX/redacted/src/main/redacted/Redacted.java: Internal compiler error: java.lang.Exception: java.lang.IllegalArgumentException: The `GraalVmProcessor` annotation processor is missing the required `log4j.graalvm.groupId` and `log4j.graalvm.artifactId` options.
19:43:55  The generation of GraalVM reflection metadata for your Log4j Plugins will be disabled. The generation of GraalVM reflection metadata for your Log4j Plugins will be disabled.
19:43:55  [ERROR] Unknown source: The `GraalVmProcessor` annotation processor is missing the required `log4j.graalvm.groupId` and `log4j.graalvm.artifactId` options.
19:43:55  The generation of GraalVM reflection metadata for your Log4j Plugins will be disabled.
19:43:55  [INFO] 2 errors 

Is anyone facing similar issue? I tried to specify the graal processor with its arguments, but that doesn't work either.

[kwakeroni]

I have the same issue.
The release notes say "the processor will fail the build if the required log4j.graalvm.groupId and log4j.graalvm.artifactId parameters are not provided", but according to this page: https://logging.apache.org/log4j/2.x/manual/plugins.html#plugin-registry the GraalVM stuff is optional.
I don't see an option to turn it off, though.

[ppkarwasz]

The warning in the release notes warning is a simplified explanation of the actual behavior. The GraalVmProcessor will only produce an error out when both of the following are true:

1. Your code includes at least one Log4j Core Plugin (i.e., you have a class annotated with @Plugin).

2. You did not supply the required compiler arguments:

   -Alog4j.graalvm.groupId=<your.groupId>
   -Alog4j.graalvm.artifactId=<your.artifactId>
   

I tested this locally (using javac in both single- and multi-module Maven setups) without any issues—no errors appeared when no @Plugin was present. Can you share a snippet or small test project where the issue does occur?

[THausherr]

            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-compiler-plugin</artifactId>
            <executions>
                <execution>
                    <id>generate-log4j-plugin-descriptor</id>
                    <goals>
                        <goal>compile</goal>
                    </goals>
                    <phase>process-classes</phase>
                    <configuration>
                        <proc>only</proc>
                        <annotationProcessorPaths>
                            <path>
                                <groupId>org.apache.logging.log4j</groupId>
                                <artifactId>log4j-core</artifactId>
                                <version>${log4j2.version}</version>
                            </path>
                        </annotationProcessorPaths>
                        <annotationProcessors>
                            <processor>org.apache.logging.log4j.core.config.plugins.processor.PluginProcessor</processor>
                            <processor>org.apache.logging.log4j.core.config.plugins.processor.GraalVmProcessor</processor>
                        </annotationProcessors>
                        <compilerArgs>
                            <arg>-Alog4j.graalvm.groupId=${project.groupId}</arg>
                            <arg>-Alog4j.graalvm.artifactId=${project.artifactId}</arg>
                        </compilerArgs>
                    </configuration>
                </execution>
            </executions>
        </plugin>

and I do have a plugin

@Plugin(name = "DebugLogAppender", category = "Core", elementType = "appender", printObject = true)
public class DebugLogAppender extends AbstractAppender

The subproject is here (the above segment has been removed because I reverted the change):
https://github.com/apache/pdfbox/tree/trunk/debugger

[ppkarwasz]

Hi @kwakeroni,

There’s no dedicated flag to turn GraalVmProcessor off, since you can effectively control it through standard compiler options.

As @ftreede mentioned, since Java 6, javac has automatically loaded all annotation processors found on the annotation processor path (which, by default, is just the classpath). This implicit behavior has been flagged as a security concern and is now deprecated as of Java 23 (see this JDK 23 heads-up and the excellent write-up here).

Keeping the spirit of the changes in JDK 23, we intentionally make GraalVmProcessor fail with an ERROR (instead of silently ignoring it or logging a warning) because:

• It helps developers become immediately aware that a new annotation processor is active.
• It forces an explicit decision: either configure it properly (opt-in) or disable it (opt-out).

✅ How to Opt-Out

Depending on whether you use other annotation processors, you can take one of two approaches:

1. You don’t use other annotation processors

You can simply disable all annotation processing:

<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-compiler-plugin</artifactId>
  <configuration>
    <!-- Completely disable annotation processing -->
    <proc>none</proc>
  </configuration>
</plugin>

2. You do use other annotation processors

In this case, declare them explicitly and isolate your annotation processor classpath:

<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-compiler-plugin</artifactId>
  <configuration>
    <annotationProcessorPaths>
      <!-- Include only specific processors, e.g. Log4j’s PluginProcessor -->
      <path>
        <groupId>org.apache.logging.log4j</groupId>
        <artifactId>log4j-core</artifactId>
        <version>2.25.0</version>
      </path>
    </annotationProcessorPaths>
    <annotationProcessors>
      <!-- List processors explicitly -->
      <annotationProcessor>org.apache.logging.log4j.core.config.plugins.processor.PluginProcessor</annotationProcessor>
    </annotationProcessors>
  </configuration>
</plugin>

This ensures that only the processors you trust and need are loaded—nothing more, nothing less.

✅ How to Opt-In

An example on to use both PluginProcessor and GraalVmProcessor is available on the documentation page you site

[ppkarwasz]

@THausherr,

I couldn't reproduce your problems with PDFBox. I submitted my changes as apache/pdfbox#207.

[THausherr]

Thank you! I also suggest that the log4j documentation be updated, with the links that you provided in your PR.

[ppkarwasz]

Hi @ratoaq2,

Thanks for the detailed error log — it's very helpful.

From what you've shared, the issue is occurring during the default-compile Maven Compiler Plugin execution, not in the custom generate-log4j-plugin-descriptor execution you configured. Specifically:

[INFO] --- compiler:3.14.0:compile (default-compile) @ common ---
[INFO] Compiling with eclipse [...] to target/classes
[ERROR] Internal compiler error: java.lang.IllegalArgumentException: 
        The `GraalVmProcessor` annotation processor is missing the required 
        `log4j.graalvm.groupId` and `log4j.graalvm.artifactId` options.

If you want to use a separate execution for annotation processing, you need to disable annotation processing in default-compile:

<execution>
  <id>default-compile</id>
  <configuration>
    <proc>none</proc>
  </configuration>
</execution>

If, on the other hand, you want to perform both compilation and annotation processing (Log4j plugin descriptor + GraalVM metadata) in a single Maven execution, you can fully configure the default-compile phase like this:

<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-compiler-plugin</artifactId>
  <version>3.14.0</version>
  <dependencies>
    <dependency>
      <groupId>org.codehaus.plexus</groupId>
      <artifactId>plexus-compiler-eclipse</artifactId>
      <version>2.15.0</version>
    </dependency>
  </dependencies>
  <configuration>
    <!-- Use Eclipse Compiler explicitly -->
    <compilerId>eclipse</compilerId>
    <release>21</release>
    <!-- Default to no annotation processing unless explicitly enabled -->
    <proc>none</proc>
  </configuration>
  <executions>
    <execution>
      <id>default-compile</id>
      <configuration>
        <annotationProcessorPaths>
          <path>
            <groupId>org.apache.logging.log4j</groupId>
            <artifactId>log4j-core</artifactId>
            <version>2.25.0</version>
          </path>
        </annotationProcessorPaths>
        <annotationProcessors>
          <annotationProcessor>
            org.apache.logging.log4j.core.config.plugins.processor.PluginProcessor
          </annotationProcessor>
          <annotationProcessor>
            org.apache.logging.log4j.core.config.plugins.processor.GraalVmProcessor
          </annotationProcessor>
        </annotationProcessors>
        <compilerArgs>
          <!-- Required arguments for GraalVmProcessor -->
          <arg>-Alog4j.graalvm.groupId=${project.groupId}</arg>
          <arg>-Alog4j.graalvm.artifactId=${project.artifactId}</arg>
        </compilerArgs>
      </configuration>
    </execution>
  </executions>
</plugin>

I hope that helps solving your problem.

[THausherr]

I tried the last change with default-compile and now the project that follows the problematic project claims that the previous package doesn't exist. I looked into the repository directory, the jar files are there, but much smaller. It turned out the class files are missing.

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-compiler-plugin</artifactId>
    <executions>
        <execution>
            <id>default-compile</id>
            <configuration>
                <proc>only</proc>
                <annotationProcessorPaths>
                    <path>
                        <groupId>org.apache.logging.log4j</groupId>
                        <artifactId>log4j-core</artifactId>
                        <version>${log4j2.version}</version>
                    </path>
                </annotationProcessorPaths>
                <annotationProcessors>
                    <annotationProcessor>org.apache.logging.log4j.core.config.plugins.processor.PluginProcessor</annotationProcessor>
                    <annotationProcessor>org.apache.logging.log4j.core.config.plugins.processor.GraalVmProcessor</annotationProcessor>
                </annotationProcessors>
                <compilerArgs>
                    <arg>-Alog4j.graalvm.groupId=${project.groupId}</arg>
                    <arg>-Alog4j.graalvm.artifactId=${project.artifactId}</arg>
                </compilerArgs>
            </configuration>
        </execution>
    </executions>
</plugin>

[ppkarwasz]

Nice catch! 💯
Somehow <proc>only</proc> ended up in my example, which disables the compilation of classes. I edited the answer to fix it.

[THausherr]

Thank you! It builds successfully now. I see you also made a (slightly different) PR, I'll have a look at it tomorrow.

[ratoaq2]

It seems I got it working with proc none plus empty annotation processors:

                <annotationProcessorPaths>
                    <path>
                        <groupId>org.apache.logging.log4j</groupId>
                        <artifactId>log4j-core</artifactId>
                        <version>${log4j2.version}</version>
                    </path>
                </annotationProcessorPaths>
                <annotationProcessors>
                    <!-- empty -->
                </annotationProcessors>

[ratoaq2]

It seems a bit cumbersome for a project that has nothing to do with Graalvm

[kwakeroni]

I agree. I have no annotation processors configured in my pom, all running out-of-the-box (like Lombok), and now I would need add about 20 lines just to turn of a feature because I'm using a custom appender (internal to the project) in my tests...

[ppkarwasz]

Thank you for your feedback!

You're absolutely right — we hadn’t fully considered the case of custom Log4j plugins used only in test code when implementing GraalVM metadata support in Log4j Core.

As a general principle, we encourage third-party Log4j Core plugins to follow the same standards as Log4j Core itself. This ensures consistent behavior across platforms and helps users discover and rely on high-quality extensions. In particular:

• We aim to list community plugins on our website (organized by type — e.g., Appenders, Layouts, Lookups), so they’re easier to find.
• We encourage support for the same platforms as Log4j Core: standard Java, JPMS, OSGi, GraalVM, and Android.

This is why we initially followed the GraalVM reachability metadata documentation strictly, which recommends placing reflect-config.json files in META-INF/native-image/<groupId>/<artifactId> — and why we introduced the -Alog4j.graalvm.groupId and -Alog4j.graalvm.artifactId compiler options to set those values explicitly.

That said, your feedback (and others') made it clear that requiring these options can be a burden in some scenarios.

Tools like picocli take a more flexible approach by making similar arguments optional, falling back to default values when not provided. Following this model, we will make the -Alog4j.graalvm.groupId and -Alog4j.graalvm.artifactId arguments optional starting in version 2.25.1. Defaults will be inferred if these are not explicitly specified, similar to how picocli handles this.

For more details on the 2.25.1 release scope and timeline, see #3766.

Thanks again for raising this — improving the developer experience for plugin authors is a priority for us.

[kwakeroni]

Thank you for taking this into account

[alexsuter]

Tried to making work with tycho-compiler-plugin. Did not find any solution to fix the build with the given configurations. Also my project has no GraalVM stuff in it.

[ppkarwasz]

I'm not a Tycho user, but from what I can tell, the configuration for tycho-compiler-plugin is quite similar to maven-compiler-plugin in this context.

I tested this successfully on a small example project using Tycho version 4.0.13 with a custom Log4j appender. To ensure the Log4j GraalVmProcessor works correctly, I added the following configuration:

<plugin>
  <groupId>org.eclipse.tycho</groupId>
  <artifactId>tycho-compiler-plugin</artifactId>
  <configuration>
    <compilerArgs>
      <arg>-Alog4j.graalvm.groupId=${project.groupId}</arg>
      <arg>-Alog4j.graalvm.artifactId=${project.artifactId}</arg>
    </compilerArgs>
  </configuration>
</plugin>

Also my project has no GraalVM stuff in it.

A quick clarification: the GraalVmProcessor is not triggered by using GraalVM itself. Instead, it is activated by the presence of custom Log4j Core plugins in your code—specifically, classes annotated with @org.apache.logging.log4j.core.config.plugins.Plugin.

Hope this helps clarify things!

[alexsuter]

This works. Thanks!