3 ms·
Have you measured this? I would expect the allocation of Callable<String> with closures to be slightly worse than common types of string concatenation. Not to
by sk5t 9y ago
Have you measured this? I would expect the allocation of Callable<String> with closures to be slightly worse than common types of string concatenation. Not to mention the awkwardness of only logging effectively final vars--this would be a red flag on organizational coding practices--just use slf4j or better yet Scala + LazyLogging.
- _old_dude_ 9y agoIf you use a closure that capture some local variables and not a constant lambda, then you're right, the allocation will kill you. But, we are only using lambdas that do not capture anything so the lambda is allocated once by the VM. And we are using the new shiny System.Logger [1] so the VM logs and the application logs are interleaved. We still have some wrappers to redirect log4j logs on the system logger because few third party libs are compatible with the system logger. [1] https://docs.oracle.com/javase/9/docs/api/java/lang/System.Logger.html https://docs.oracle.com/javase/9/docs/api/java/lang/System.L...
- sk5t 9y agoAh, makes sense. On the other hand, this would seem to take a StringBuilder-based approach off the table (cf. logback). I wonder how this stacks up to simply passing varargs to the logger. There's also the question of applying any strategy other than toString to the non-string args.