Let me expand on this question with further context as it relates to why the
annotation processor exists in the first place. Back when the initial plugin
system was developed by Ralph, we had an option to specify a comma-separated
list of packages to scan for plugins (note that scanning the entire classpath
was and still is a poor way to implement this), and we had a default package in
the code to scan for log4j-core plugins. Everything still leads back to this
general need for discovering the list of classes and their corresponding plugin
metadata (primarily the plugin name which is used for configuring things like
`<console name=“foo”>…` or `<appender type=“console” name=“foo”>…` rather than
`<appender type=“org.apache.logging.blah.blah.blah” name=“foo”>…` as well as
the category/namespace) so that various configurable classes are instantiated
from the parsed configuration data. This can be sort of compared to use of
things like type discriminators in JSON where types are all resolved against
plugin names rather than arbitrary class names.
To alleviate this scan, we started with a cache file that dumped out metadata
about plugins discovered from reflection-based classpath scanning (via a class
in log4j-core with a main method). Later on, we added an annotation processor
that did the same thing as this bundled program. In 3.x, we replaced this cache
file with generated Java code implementing a ServiceLoader-loaded class that is
almost exactly the same thing as what the cache file did before (serialize and
deserialize a list of PluginEntry instances through some format supported by
core Java).
So now we come to your question about a factories file. That’s an interesting
idea, though it’s extremely similar to what we’re doing here with ServiceLoader
(though the split between META-INF/services/ files and module-info.java
provides/uses entries is confusing). Moving away from ServiceLoader to a custom
mechanism might be more flexible, though I’m not very knowledgeable about how
Java modules work with them.
If you examine the output of a generated plugin service file from the
annotation processor, you may see that it’s something that you can easily write
by hand, but it’s tedious as it’s replicating information from the plugin
annotations into PluginEntry instances.
—
Matt Sicker
> On Oct 22, 2023, at 14:35, Volkan Yazıcı <vol...@yazi.ci> wrote:
>
> Good point Matt! Annotation processing has always been an unpleasant magic
> to work with from a developer perspective for the reasons you shared. What
> are our alternatives? Can't we offer a `META-INF/log4j.factories`
> functionality similar to Spring Boot? If so,
>
> 1. What are its cons/pros for users?
> 2. What are its implementation requirements (for the Log4j crew) roughly?
>
>
> On Fri, Oct 20, 2023 at 7:40 PM Matt Sicker <m...@musigma.org> wrote:
>
>> Snippet from the JDK 21 announcement email that pertains to us. While the
>> annotation processor was initially developed to try to be implicit and
>> magic, as we’ve seen both in our build and in IDEs, annotation processing
>> is typically either disabled by default (in IDEs) or sometimes requires
>> manual setup anyways (like in our build). It sounds like starting in Java
>> 22, implicit annotation processing will no longer be available. We’ll need
>> to ensure our docs about this mention that you need to enable annotation
>> processing in your build, too.
>>
>>> Begin forwarded message:
>>>
>>> From: David Delabassee <david.delabas...@oracle.com>
>>> Subject: JDK 21 Is Now GA, a New VS Code Extension, and an Annotation
>> Processing Heads-up
>>> Date: October 20, 2023 at 4:39:07 AM CDT
>>> To: "dev@logging.apache.org" <dev@logging.apache.org>
>>> Reply-To: dev@logging.apache.org
>>> List-Id: <dev.logging.apache.org>
>>>
>>> ## Heads-Up - JDK 22: Implicit Annotation Processing Behavior Change
>>>
>>> As discussed in the July 2023 Quality Outreach update [8], starting in
>> JDK 21 javac emits a note if _implicit_ annotation processing is being
>> used, that is, if one or more annotation processors are found and run from
>> the class path when no explicit annotation processing configuration options
>> are used.
>>>
>>> The note is reported since, quoting from the note text: "A future
>> release of javac may disable annotation processing unless at least one
>> processor is specified by name (-processor), or a search path is specified
>> (--processor-path, --processor-module-path), or annotation processing is
>> enabled explicitly (-proc:only, -proc:full)."
>>>
>>> That future version of javac has arrived in JDK 22 b19+ with JDK-8306819
>> ("Consider disabling the compiler's default active annotation processing").
>> In the situation where a note was emitted in JDK 21, in JDK 22 no note is
>> emitted, and annotation processors are *not* run. To restore the previous
>> behavior with respect to running annotation processors, add the
>> '-proc:full' javac option.
>>>
>>> Feedback on the annotation processing policy change can be sent to
>> compiler-dev [9].
>>>
>>> [8]
>> https://mail.openjdk.org/pipermail/quality-discuss/2023-July/001122.html
>>> [9] https://mail.openjdk.org/mailman/listinfo/compiler-dev
>>
>>
