Feedback on Message and LogBuilder pooling in JUL and Logback

[ppkarwasz]

Hi all,

I’m opening this thread to gather (belated) feedback from JUL and Logback users regarding a behavioral change introduced in version 2.23.0 of the log4j-to-jul and log4j-to-slf4j bridges.

Since that version, both bridges use the simpler ParameterizedMessageFactory, and no longer switch to the ReusableMessageFactory even when the log4j2.enableThreadlocals property is set to true. This differs from the behavior of Log4j Core.

The rationale behind this change, as far as I recall from discussions with other maintainers:

• Alignment with target backends: Neither JUL nor Logback (the only native SLF4J implementation) are designed for GC-free logging. Logback creates a new LoggingEvent for each call, and the default JUL implementation also lacks any object pooling. Using ParameterizedMessageFactory, which creates a fresh Message per log event, is therefore more consistent with their design philosophies.

• Memory usage concerns: ReusableMessageFactory relies on thread-local storage, which incurs a small but non-trivial per-thread memory cost—typically a few KiB, but potentially several MiB across large thread pools. This behavior is well-documented and expected in Log4j Core, but could come as a surprise when using bridge modules like log4j-to-jul or log4j-to-slf4j.

• Simplicity and reliability: The simplicity of ParameterizedMessageFactory also reduces potential issues. Unlike ReusableMessageFactory, it doesn’t depend on thread-local state, making it easier to reason about and more robust—especially appealing for users of JUL, who often seek minimalistic logging setups without advanced features.

We’d like to hear your thoughts:

• Do you find this change appropriate for the JUL and SLF4J/Logback logging frameworks?
• Would you prefer if the choice of MessageFactory remained configurable for these bridges?

Your feedback would help us fine-tune future development, especially as we transition the JUL and SLF4J bridges to the new logging-jdk and logging-slf4j subprojects. These projects are decoupled from the Log4j Core lifecycle, allowing them to better track changes in JUL and Logback moving forward.

Thanks in advance for your input!