C and C++ are harder to read as a side effect of pre-processor macros. IMHO, Java's lack of pre-processor macros simplifies the language and improves readability.
On 4/7/2022 9:01 PM, Ralph Goers wrote: > I mentioned this same concern back in 2017 when the Sun Reflection > class was removed. > > 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. > I wrote a Logging Framework for C back in the 1980’s that could include the > Information so this isn’t a new concept. > > Even if I could do > > logger.debug(System.location(), ….) > > Where System.location is replaced by the compiler with a constant object > would be a huge win. > > Ralph > > > >> On Apr 7, 2022, at 11:02 AM, Bernd Eckenfels <e...@zusammenkunft.net> wrote: >> >> Some loggers do need to find the location of the log statement (class and >> line where the logger is used not where it is instantiated). >> >> for those (it makes loggers more useful) getting the call site is time >> critical even if they are not in tight performance critical loops. >> >> But it actually does matter if/how the JVM optimizes such introspection.. if >> the JVM can inline (and maybe even constant intrinsic) the stalkwalker it >> would benefit such use cases just as well. >> >> -- >> https://bernd.eckenfels.net >> ________________________________ >> From: core-libs-dev <core-libs-dev-r...@openjdk.java.net> on behalf of >> Michael Kuhlmann <j...@fiolino.de> >> Sent: Thursday, April 7, 2022 7:55:16 PM >> To: core-libs-dev@openjdk.java.net <core-libs-dev@openjdk.java.net> >> Subject: Re: fast way to infer caller >> >> >> >> On 4/7/22 19:27, Kasper Nielsen wrote: >>>> >>>> nope, see my previous mail to Ceki, the VM is cheating here if it can >>>> inline the call to MethodHandles.lookup() >>>> >>> >>> Does how the VM cheats really matter? The fact is that the code in the JDK >>> can >>> get the calling class and implement something like MethodHandles.lookup() so >>> it takes ~3 ns. If you implemented something like a lookup class as a normal >>> user your best bet would be StackWalker.GetCallingClass() and you would end >>> up with something that is at least 2 magnitudes slower. That is probably not >>> an issue for most use cases. But for some, it might be a bit of a steep >>> cost. >>> >>> /Kasper >> >> Hi Kasper, >> >> sorry to jump in here as an uninvolved onlooker, but I can't resist. >> I really don't see why this should matter. Getting the caller class is a >> rare edge case that you just do in exceptional situations; most often >> it's more for debugging or something. >> >> What users really are interested in is high performance for standard >> cases. Implementing a specific optimization into Hotspot to gain few >> milliseconds is the least thing I expect from the JVM developers. >> >> I also don't understand why someone should instantiate a logger during >> performance critical procedures. In more than 20 years of Java >> development, I've never seen the need to create a logger on the fly. >> They are *always* assigned to final static variables, or at least to >> predefined pools. Everything else would be just wrong: To instantiate a >> logger, you have to fetch at least the log level definition from some >> configuration source, and this can never be fast. At least not that >> we're talking about nanoseconds here. >> >> All logging implementations I know of (and all that make sense) are >> highly optimized on log throughput; this can only be achieved by >> preprocessing during initialization, why this is slow. But that doesn't >> matter, because, as said, you should anyway create logger instances >> beforehand. >> >> Sorry for the rant, but I really don't see the use case here. > -- Ceki Gülcü Sponsoring SLF4J/logback/reload4j at https://github.com/sponsors/qos-ch
