fast way to infer caller
Michael Kuhlmann
jdk at fiolino.de
Fri Apr 8 05:56:57 UTC 2022
Good morning!
On 4/7/22 23:59, Kasper Nielsen wrote:
> Hi Michael,
>
> I don't really have an opinion on how you obtain a logger. But one
> particular
> use-case I've had was that I would like to perform some access checks based
> on the module of the caller. Something similar to how Panama checks for
> native access:
>
> Reflection.ensureNativeAccess(Reflection.getCallerClass());
Hmh, but wouldn't it be sufficient to perform these checks at
initialization time?
On 4/7/22 21:01, Ralph Goers wrote:
> In Log4j’s case there are two places that accessing the stack comes
into play:
> 1. Obtaining a Logger .
> 2. Logging an event and including the caller’s location information.
>
> To be honest, what sucks for Logging frameworks is that we really want
> access to the location information at compile time such that the overhead
> to include it would be zero. I’ve never understood why Java doesn’t
include it.
That I totally agree! Having the exact line number in the log statement
would be a huge win.
But to be honest, Reflection::getCallerClass wouldn't help either.
I agree that such an inlined statement would be a huge win.
But to also put this into relation: From my opinion, logging frameworks
should be most performant in the cases where they are *not* logging. Or
in those cases where you would log a lot even in production environment
- like for financial calculations - the exact line number isn't that
relevant any more.
But that's just my opinion.
-Michael
More information about the core-libs-dev
mailing list