Github user remkop commented on the issue:
https://github.com/apache/logging-log4j2/pull/148
Please ignore my previous comment.
On closer inspection, I realized that `MutableLogEvent::getFormat` and
`RingBufferLogEvent::getFormat` currently already return `null`
unconditionally, and return `this` from their `getMessage` method, so current
custom user code already has to deal with `null` values from
`Message::getFormat`.
I'm generally okay with the proposed changes.
I'm not sure that it is a good idea to make the decision on whether to
return `null` or not hinge on whether returning a non-null String would create
garbage. it may be more consistent to always return `null` from `Message`
implementations that do not have embedded curly braces. But the proposed
implementation is also ok.
---