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