[ 
https://issues.apache.org/jira/browse/LOG4J2-1329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15215108#comment-15215108
 ] 

Remko Popma commented on LOG4J2-1329:
-------------------------------------

 I would like to keep the StringBuilderFormattable interface narrow and focused 
(and a nice benefit of keeping it to one method is that it can be used as a 
functional interface in Java eight lamdas).

Looking at your original message, there's something I don't understand. 
{quote}
I think it will be difficult to adapt all layouts (and appenders without 
layouts) to use StringBuilderFormattable.formatTo(StringBuilder) instead of 
String Message.getFormattedMessage().

I suggest we add another method to StringBuilderFormattable:

CharSequence getFormattedMessageBuffer(); // feel free to suggest a better name

That method could just return the StringBuilder, and be equally allocation 
free. The each layout / appender can use whichever method is easiest in that 
case.

I am looking at GelfLayout, and it would be easier to use a method returning a 
CharSequence instead of formatTo(StringBuilder).
{quote}

Generally I would expect that Layouts manage their own their own buffer to 
build a log event representation. It seems a bit strange that the layout would 
need to "borrow" the buffer from one of the log event components. (And Messages 
may not always _have_ a buffer.)  I need to look at GelfLayout, perhaps I'm 
missing something. 
 

> API change: let Message.getFormattedMessage() return CharSequence instead of 
> String
> -----------------------------------------------------------------------------------
>
>                 Key: LOG4J2-1329
>                 URL: https://issues.apache.org/jira/browse/LOG4J2-1329
>             Project: Log4j 2
>          Issue Type: Improvement
>          Components: API
>    Affects Versions: 2.5
>            Reporter: Remko Popma
>
> I propose that we change {{Message.getFormattedMessage()}} to return a 
> {{CharSequence}} instead of a String.
> I believe this change would be backwards compatible (all Message 
> implementations that return a String will work as is), and it opens the way
> for zero-GC Message implementations to return a cached StringBuilder as 
> Mikael [suggested on the log4j-dev mailing 
> list|http://mail-archives.apache.org/mod_mbox/logging-log4j-dev/201603.mbox/%3CCAAFrFhSs4EqjOERwHObKAZP4wjGWeiCET1nyE1FVndYdePk2yw%40mail.gmail.com%3E].



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

Reply via email to