With this method or any similar method,    public void info(String format, Object... arguments) {        if (isInfoEnabled()) {            handleArgArrayCall(Level.INFO, null, format, arguments);        }    }If the number of objects in 'arguments' is more than the number of placeholders, {}, the extra argument objects are not logged.  Is there a reason for that? For example  public void setTemperature(Integer temperature) {       oldT = t;            t = temperature;  //Sent three parameters log with two placeholders  //Output "Temperature set to 90. Old value was null."  The word extra is not printed    logger.info("Temperature set to {}. Old value was {}.", t, oldT, "extra");    if(temperature.intValue() > 50) {      logger.info("Temperature has risen above 50 degrees.");    }  } If I get into a situation where I have sent more argument objects than placeholders that it should append those un-placed arguments to the end of the logged string.  The intent of the developer is to have the parameter logged.  Finding this out from production is not good.  What is sent to be logged is important information, depending on the log level. My use case is that I want to push some legacy code to start looking like SLF4J so we can migrate away from the older pattern filled with isLogTraceEnabled calls.  I learned of the above when I was writing JUnit tests to see all the things the code would do and not do. I feel that https://www.slf4j.org/faq.html#logging_performance is telling me that, in some way, the placeholder string substitution is faster than appending multiple strings together.  I understood the main point of the argument as converting items to string before I needed them was where the overhead was.  Keeping them as type Object reduces that overhead. I understand there are Sonarqube rules and PMD to prevent me from not having the correct number of argument objects.  This would help, but I feel like there are still going to be misses.  Since my code is custom, Sonarqube and PMD do not feel like options.