I concede on the performance. It is been a while since I have attempted micro benchmarks particularly with the modern logging backends. Its also not my area of expertise.
But the chicken/egg problem is real albeit solvable particularly with more powerful logging backends. My little wrapper proposition seems like a pretty crappy idea now... oh well. It did help us with some issues (chicken/egg and some fringe case unit testing issues). On Sat, Mar 18, 2017 at 5:17 PM, Joachim Durchholz <[email protected]> wrote: > Am 18.03.2017 um 21:26 schrieb Adam Gent: >> >> I mean I generally agree my arguments are fairly weak because I'm >> defending a small minority of libraries. That is part because >> libraries that have these problems (chicken/egg, performance issues) > > > I still need to see how these problems even exist. > >> just avoid logging all together or write their own (e.g. >> https://github.com/EsotericSoftware/kryo has its own). > > > Kryo does its own logging not due to chicken/egg problems but because Nathan > believes the complexity of an extra logger implementation is totally worth > it if you can optimize out the logger.trace calls statically. > It's a minority position, and one that I don't share because if we really > start to count function calls then Java isn't the right tool for the job > anyway. > What happened is that people stopped arguing with Nathan and started writing > an SLF4J adapter for Kryo, which seems to be working fine. > _______________________________________________ > slf4j-user mailing list > [email protected] > http://mailman.qos.ch/mailman/listinfo/slf4j-user -- CTO SnapHop (snaphop.com) (twitter) @agentgt (linkedin) http://www.linkedin.com/in/agentgt (cell) 781-883-5182 _______________________________________________ slf4j-user mailing list [email protected] http://mailman.qos.ch/mailman/listinfo/slf4j-user
