Details
-
Improvement
-
Resolution: Unresolved
-
Minor
-
None
-
1.7.x
-
None
-
None
Description
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.