Hi Ralph, On Wed, 4 Jan 2023 at 01:42, Ralph Goers <ralph.go...@dslextreme.com> wrote: > I do like this as a separate repo. If I understand what you are intending I > expect that releasing this tool will be big news:
At least I hope it will be big news, previous attempts like SLF4J Migrator[1] do not seem to be very popular, probably because they lack binary support. > 1. It automatically converts calls to SLF4J to Log4j, eliminating the need to > include the SLF4J and log4j-slf4j-impl jars at runtime. Yes, I believe this might be popular with projects that mostly use Log4j2 API, but have that pesky little dependency that uses SLF4J. A practical example: at work we have a 'com.vaadin.external.atmosphere:atmosphere:runtime'[2]. This modified version of Atmosphere uses a rebased SLF4J, that only offers JUL as a backend. It will the first to go under the knife. > 2. It adds location information for free for both SLF4J and Log4j API calls, > which should be a significant performance improvement. According to our own benchmarks[3] using `LogBuilder` is about 2.5 times slower than using `Logger` *without* location. We probably need to fill this gap. > One gotcha we will need to make sure is accounted for is the use of Lombok. > Will the tool be able to find the Logger created by Lombok? Yes, Lombok runs at compilation time. When the tool post-processes the bytecode, it will find everything it needs. BTW, I have found an OpenRewrite plugin[4] that rewrites logging frameworks. So I'll just need to send them a big PR with an "everything to Log4j2" rule. Piotr [1] https://www.slf4j.org/migrator.html [2] https://mvnrepository.com/artifact/com.vaadin.external.atmosphere/atmosphere-runtime [3] https://logging.apache.org/log4j/2.x/manual/logbuilder.html [4] https://github.com/openrewrite/rewrite-logging-frameworks
