logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Remko Popma (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (LOG4J2-1326) API change: add methods for logging CharSequences (was: Provide support for CharSequence parameters for low and zero-GC applications)
Date Fri, 25 Mar 2016 16:46:25 GMT

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

Remko Popma edited comment on LOG4J2-1326 at 3/25/16 4:45 PM:
--------------------------------------------------------------

The String versions of the methods need to remain because removing them would result in NoSuchMethodErrors
in user code that was compiled against the current log4j API. I would not deprecate the String
methods (we will never remove these methods in the 2.x version and the compiler warnings would
just be annoying, not helpful).

AbstractLogger would have one-line implementation of these methods similar to what's already
there.

Matt is right that by changing the existing ObjectMessage implementation to do an {{instanceof
CharSequence}} check we can achieve the desired behaviour with the existing {{debug(Object)}}
etc. methods without API changes. Most of the benefit of this proposal is in communicating
to users that by letting their Objects implement CharSequence these Objects can be logged
without creating garbage. This is not obvious with the current API.

I guess the question is whether this communicative aspect justifies the additional methods.

(Vlad, David, feel free to add your feedback. I could be wrong or missing something.)


was (Author: remkop@yahoo.com):
The String versions of the methods need to remain because removing them would result in NoSuchMethodErrors
in user code that was compiled against the current log4j API. I would not deprecate the String
methods (we will never remove these methods in the 2.x version and the compiler warnings would
just be annoying, not helpful).

AbstractLogger would have one-line implementation of these methods similar to what's already
there.

Matt is right that by changing the existing ObjectMessage implementation to do an {{instanceof
CharSequence}} check we can achieve the desired behaviour with the existing {{debug(Object)}}
etc. methods without API changes. Most of the benefit of this proposal is in communicating
to users that by letting their Objects implement CharSequence these Objects can be logged
without creating garbage. This is not obvious with the current API.

I guess the question is whether this communicative aspect justifies the additional methods.

> API change: add methods for logging CharSequences (was: Provide support for CharSequence
parameters for low and zero-GC applications)
> -------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: LOG4J2-1326
>                 URL: https://issues.apache.org/jira/browse/LOG4J2-1326
>             Project: Log4j 2
>          Issue Type: New Feature
>          Components: API
>    Affects Versions: 2.5
>            Reporter: Vlad Shurupov
>              Labels: features, performance
>
> Currently, the preferred way of logging character sequences in log4j 2 is by passing
in tokens of type {{java.lang.String}}. It would be very beneficial if the API could provide
methods that take {{java.lang.CharSequence}} tokens. This would allow high performance zero
or low-GC applications to re-use the existing mutable structures implementing {{java.lang.CharSequence}}
 for continuous logging without new objects being created.
> A high-performance implementation of the logger would be expected to copy out the contents
of a single or multiple instances of {{java.lang.CharSequence}} so that they could be re-used
in the subsequent logging call.



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

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


Mime
View raw message