Re: [log4j] Annotation processing alternatives
We really don’t have much choice. With JPMS you really need to use ServiceLoader to locate things like plugins across modules. Using a s file like spring.factories doesn’t really help anyway. You wouldn’t want to force users to hand create the entries in that file and so would use annotations and a processor to populate it, which is exactly what we are doing. Ralph > On Oct 23, 2023, at 10:12 AM, Gary Gregory wrote: > > Staying from the built-in Service Loader is a recipe for even more > custom code and complications. I say we stick with the built-in > Service Loader. > > Gary > >> On Sun, Oct 22, 2023 at 5:01 PM Piotr P. Karwasz >> wrote: >> >> Hi Matt, >> >>> On Sun, 22 Oct 2023 at 22:49, Matt Sicker wrote: >>> 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. >> >> I think that `ServiceLoader` is the only standard feature that is >> supported by both OSGi and JPMS. If we move away from it, we'll need >> some custom code to support it (or `opens`, etc). I wouldn't go that >> way. >> >> Piotr
Re: [log4j] Annotation processing alternatives
So really, the question is whether we can make the generated service classes easier to create without annotation processing? > On Oct 23, 2023, at 12:11 PM, Gary Gregory wrote: > > Staying from the built-in Service Loader is a recipe for even more > custom code and complications. I say we stick with the built-in > Service Loader. > > Gary > > On Sun, Oct 22, 2023 at 5:01 PM Piotr P. Karwasz > wrote: >> >> Hi Matt, >> >> On Sun, 22 Oct 2023 at 22:49, Matt Sicker wrote: >>> 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. >> >> I think that `ServiceLoader` is the only standard feature that is >> supported by both OSGi and JPMS. If we move away from it, we'll need >> some custom code to support it (or `opens`, etc). I wouldn't go that >> way. >> >> Piotr
Re: [log4j] Annotation processing alternatives
Staying from the built-in Service Loader is a recipe for even more custom code and complications. I say we stick with the built-in Service Loader. Gary On Sun, Oct 22, 2023 at 5:01 PM Piotr P. Karwasz wrote: > > Hi Matt, > > On Sun, 22 Oct 2023 at 22:49, Matt Sicker wrote: > > 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. > > I think that `ServiceLoader` is the only standard feature that is > supported by both OSGi and JPMS. If we move away from it, we'll need > some custom code to support it (or `opens`, etc). I wouldn't go that > way. > > Piotr
Re: [log4j] Annotation processing alternatives
Hi Matt, On Sun, 22 Oct 2023 at 22:49, Matt Sicker wrote: > 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. I think that `ServiceLoader` is the only standard feature that is supported by both OSGi and JPMS. If we move away from it, we'll need some custom code to support it (or `opens`, etc). I wouldn't go that way. Piotr
Re: [log4j] Annotation processing alternatives
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 `…` or `…` rather than `…` 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ı 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 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 >>> 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" >>> Reply-To: dev@logging.apache.org >>> List-Id: >>> >>> ## 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/listin
[log4j] Annotation processing alternatives
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 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 > > 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" > > Reply-To: dev@logging.apache.org > > List-Id: > > > > ## 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 > >