I am against polluting (actually, almost doubling!) our public API just because we couldn't figure out how to weave bytecode in the way we want.
For the records, specialization will be inevitable for transforming SLF4J and Log4j 1 calls. On Tue, Jul 12, 2022 at 10:49 PM Piotr P. Karwasz <piotr.karw...@gmail.com> wrote: > Hi Volkan, > > > My next step will be to run this at compile time. (Will keep you posted.) > > > > Please note the specialization on `Logger#info(String)` call in > > `AppTransforming`. Since Ralph did not like thread-locals, we need to > > implement every such possible specialization of the public API. > > I think we just need a helper class that has a static method for each > method of the `Logger` class. E.g. for `Logger#info(String)` we can > have `LoggerUtil#info(Logger, String, int)`. Since the signatures are > almost identical we just need to push the location index onto the > stack and replace the call of one method with the other. Since the > util methods will be very short, the JIT compiler will end up inlining > them and we don't have to play with the order of the arguments at a > bytecode level. > > I have a working prototype here: > https://github.com/ppkarwasz/asm-playground > > The main problem with the prototype is that it adds a static field to > the woven class, but that can be corrected by either generating an > internal class or using an external registry like you do. > > Piotr >
