[
https://issues.apache.org/jira/browse/LOG4J2-1293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15156486#comment-15156486
]
Ralph Goers commented on LOG4J2-1293:
-------------------------------------
I kind of wish I had thought of this in the first place.
I don't think Message should extend it in 2.x as that will break compatibility.
> GC-friendly Message API enhancement
> -----------------------------------
>
> Key: LOG4J2-1293
> URL: https://issues.apache.org/jira/browse/LOG4J2-1293
> Project: Log4j 2
> Issue Type: Improvement
> Components: API
> Affects Versions: 2.5
> Reporter: Remko Popma
>
> Currently the only way to get the content of a {{Message}} object is to call
> its {{getFormattedMessage()}} method, which returns a String. This requires
> several temporary objects.
> Proposal: introduce a new interface:
> {code}
> public interface StringBuilderFormattable {
> void formatTo(StringBuilder buffer);
> }
> {code}
> We can either let {{Message}} extend StringBuilderFormattable, or only let
> the current Message implementation classes implement this interface.
> The first option is more elegant: downstream code does not need to use
> {{instanceof}} to detect if the formatTo() method is available. The downside
> is that user's custom Message implementations need to be modified and
> recompiled.
> Side note:
> Having a separate interface for this method has the advantage that client
> code objects that implement this interface can be converted to text without
> allocating temp objects:
> {code}
> // gc-free if currentState implements StringBuilderFormattable
> logger.trace("my state is: {}", currentState);
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
