...

Imitate the user's behavior by manually adding or replacing the dependent logging jars and assigning the corresponding system property by -Dslf4j.provider .
After that, try starting a Kafka service and see if there are any warnings or errors. Make sure Kafka still usually works after changing the logging framework.

Rejected Alternatives

Delivering this KIP in a minor version

• We cannot ensure SLF4J 2.x would work like 1.x out of the box for client modules. This would potentially break backward compatibility, which violates Kafka's commitment to compatibility in minor releases.
• Solutions involving warnings and classpath ordering do not provide robust solutions to compatibility challenges. Such approaches would introduce fragility and unpredictability to deployment environments, especially in complex production settings where Kafka is commonly used.
• Version matching between the SLF4J core and providers is critical, as documented in the SLF4J FAQ (https://www.slf4j.org/faq.html#compatibility). A major version change like this requires careful coordination that is more appropriate for a major release.

Using java.util.logging

• Kafka already uses SLF4J, and most of the Java ecosystem standardizes on SLF4J as the logging facade. This maintains compatibility with existing configurations and tooling.
• The goal of this KIP is to leverage SLF4J2's provider selection capabilities while minimizing disruption, not to fundamentally change Kafka's logging architecture.