[ https://jira.qos.ch/browse/SLF4J-468?page=com.atlassian.jira.plugin.system.i... ] Ceki Gülcü commented on SLF4J-468: ---------------------------------- With hindsight, I think {MessageFormatter}} does too much. It formats the message with arguments and also normalizes the argArray and the throwable via the {{FormattingTuple}}. I think the code would be cleaner if {{MessageFormatter}} did only formatting and the normalization of the arguments was done somewhere else, for example by the printing methods (debug, info, etc) as done in {{EventRecordingLogger}}. I suggest creating a new class, say {{MessageFormatter2}} (name to be discussed) with methods that do not handle the throwable nor return a {{FormattingTuple}}. The actual formatting code could have variants taking 1, 2 or more arguments without the necessity to create intermediary {{Object[]}}.

MessageFormatter codepath improvements in case of one and two Object parameters -------------------------------------------------------------------------------

Key: SLF4J-468 URL: https://jira.qos.ch/browse/SLF4J-468 Project: SLF4J Issue Type: Improvement Affects Versions: 1.7.x Reporter: Wessel van Norel Assignee: SLF4J developers list Priority: Minor

The pseudo path the code follows in case of one argument is: org.slf4j.helpers.MessageFormatter#format(java.lang.String, java.lang.Object) create Object Array with size one and put the parameter in it get length of array check if Element[length -1] of this Array is a Throwable if throwable     create empty object array     create new Stringbuffer to contain message     append message to Stringbuffer     return Stringbuffer else     normal codeflow to format the message with argument fi The flow around a Throwable is suboptimal, which is logical since you should not be calling this with just a Throwable. But by adding a instanceof call to this method and then calling org.slf4j.helpers.MessageFormatter#arrayFormat(java.lang.String, java.lang.Object[], java.lang.Throwable) directy with the proper parameters safes the get & check in the array and in case of Throwable the new array and unneeded stringbuffer creation. Skipping the instanceof call might result in undesired behaviour in case a logger implementation is calling this formatter even though it has no need for it. I would suggest that for 2.0.0 the instanceof check is not added, but for 1.7.x it contains it, so the library behaves as before the change, but a little bit faster.   The pseudo code path for the 2 argument version is: org.slf4j.helpers.MessageFormatter#format(java.lang.String, java.lang.Object, java.lang.Object) create Object Array with size two and put both parameters in it get length of array check if Element[length -1] of this Array is a Throwable if Throwable     create object array with size 1 and copy first element of the size two array into it     normal codeflow to format the message with argument else     normal codeflow to format the message with arguments fi With an instanceof and then directly calling org.slf4j.helpers.MessageFormatter#arrayFormat(java.lang.String, java.lang.Object[], java.lang.Throwable) safes some processing in both cases.

-- This message was sent by Atlassian JIRA (v7.3.1#73012)