Changes under consideration for SLF4J version 2.1.0

[ceki]

We are looking for feedback regarding two SLF4J API changes under consideration for version 2.1.0.

The changes under consideration are discussed in separate pages:

• MDCAmbit
• fluent API additions
• MDC + Context Propagation Feature Request
• bump the Java requirement to version 11 instead of Java 8

You can make new requests below.

[michael-o]

As mentioned #379, 2.x should stay on Java 8 for the time being.

[dmatej]

Actually I would vote to go to 17 at least. Even Jakarta EE goes for 21 and just for few projects still supports 17.

[arkamsterdam]

I always include something like the class below into my projects. I would very much like to see this standardised, either as a utility method or directly as an added getLogger method in the LoggerFactory class. Off course, this would need Java 9 as it uses theStackWalker api.

package com.example;

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import java.lang.StackWalker.StackFrame;
import static java.lang.StackWalker.Option.RETAIN_CLASS_REFERENCE;

public abstract class ClassLogger {

    private static final Class<?> DEFAULT_CLASS_LOGGER = ClassLogger.class;

    private ClassLogger() {
    }

    /**
     * Typically inside a class {@code MyClass} one would create a {@code Logger} like
     *  {@code LoggerFactory.getLogger(MyClass.class)}.
     * This utility method allows you to leave out the class parameter. The class that calls this method is then
     * used to create a {@code logger}.
     *
     * @return an SLF4J @{code Logger} with a name that equals the name of the class of the calling method
     */
    public static Logger create() {
        StackWalker walker = StackWalker.getInstance(RETAIN_CLASS_REFERENCE);
        Class<?> callerType = walker.walk(stream -> stream.skip(1).findFirst()
                .map(StackFrame::getDeclaringClass)
                .orElse(DEFAULT_CLASS_LOGGER));
        return LoggerFactory.getLogger(callerType);
    }
}

[ppkarwasz]

Basically you are looking for an equivalent of the LogManager.getLogger() method from the Log4j API?

Such a feature does not require Java 9. It can be implemented with any Java version.

[arkamsterdam]

If one uses Log4j, then yes that method is available. The question however was for new features in Slf4j. I mostly use Slf4j with Logback as implementation.

And yes, the method above could be recreated in any version of Java if one creates an exception and retrieves the class name of the calling class from the stack trace in that exception. But that is not the point. My reply should be read as an implicit 'yes' to the question 'should we bump to Java version 11?'. And that is of course next to the explicit call for this added functionality.

[cjw129]

Please, add info(String format, Supplier<?>... args) method to Logger class. Here is the guide that my company gave me to modify the code. But slf4j is not supported, so it is difficult to explain to other developers. T^T
https://docs.pmd-code.org/latest/pmd_rules_java_bestpractices.html#guardlogstatement

[ppkarwasz]

SLF4J already supports j.u.f.Supplier in its LoggingEventBuilder interface, e.g.:

log.atDebug().addArgument(this::calculateExpensiveLoggingTest).log("log something expensive: {}");

The example you see on the PMD page only applies to Log4j API (version 2.4 or higher):

log.debug("log something expensive: {}", this::calculateExpensiveLoggingText);

Note: IMHO guard log statements are a bad practice in SLF4J, since they prevent logging backend features such as Logback's turbofilters or Log4j Core's global filters from working correctly: the log statement is skipped before those filters get a chance to evaluate it.

[cjw129]

The example you see on the PMD page only applies to Log4j API (version 2.4 or higher):

So I would like to ask Slf4j to provide the same API to explain to other developers according to the method shown in the guide.