You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by "Nick Williams (JIRA)" <ji...@apache.org> on 2014/04/09 18:27:20 UTC
[jira] [Comment Edited] (LOG4J2-599) Support lambda functions (or
similar) for log message parameters
[ https://issues.apache.org/jira/browse/LOG4J2-599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13964339#comment-13964339 ]
Nick Williams edited comment on LOG4J2-599 at 4/9/14 4:26 PM:
--------------------------------------------------------------
To be clear, {{toString}} of a {{Supplier}} is completely meaningless. It'll look something like "com.MyClass$$Lambda$1/1130971279@5114b3a8". If someone provides a {{Supplier}}, they don't mean for you to call {{toString}} on it. {{Callable}}, on the other hand, I can see your point. Maybe we only support a "smart API" for {{Supplier}}?
The problem with a separate API is it actually makes it MORE difficult to use. What if MOST of my arguments are simple, but ONE of them needs to be evaluated on a deferred basis? Consider this:
{code:java}logger.trace("Enter {} {} {} {}", argument1, argument2, (Supplier)() -> argument3.someMethod(), argument4);{code}
Having a separate Supplier API would make this impossible. They'd have to use a lambda for all four arguments.
was (Author: beamerblvd):
To be clear, {{toString}} of a {{Supplier}} is completely meaningless. It'll look something like "com.MyClass$lambda$18972349\ou98!uc". If someone provides a {{Supplier}}, they don't mean for you to call {{toString}} on it. {{Callable}}, on the other hand, I can see your point. Maybe we only support a "smart API" for {{Supplier}}?
The problem with a separate API is it actually makes it MORE difficult to use. What if MOST of my arguments are simple, but ONE of them needs to be evaluated on a deferred basis? Consider this:
{code:java}logger.trace("Enter {} {} {} {}", argument1, argument2, (Supplier)() -> argument3.someMethod(), argument4);{code}
Having a separate Supplier API would make this impossible. They'd have to use a lambda for all four arguments.
> Support lambda functions (or similar) for log message parameters
> ----------------------------------------------------------------
>
> Key: LOG4J2-599
> URL: https://issues.apache.org/jira/browse/LOG4J2-599
> Project: Log4j 2
> Issue Type: Brainstorming
> Components: Core
> Reporter: Matt Sicker
> Priority: Minor
>
> It would be nice if we could support 0-param lambda functions (or the equivalent: interfaces with a single empty-parameter message call), or more simply, allow Runnables (or something similar) to be passed which will be dynamically executed if the log message is enabled.
> The use case here is that although string construction of the log message is a performance issue that is already solved quite well, the problem of adding in information to the log message that makes other calculations still needs to be wrapped in an if check.
> I'm not sure if it'd be best to just use Runnable, or create a new interface, or try to emulate how Java 1.8 lambdas work via an interface with a single method defined. The details here would still need to be fleshed out, but I think this sort of feature could be rather handy (especially in a Java 1.8+ environment, or in Groovy/Scala/etc.).
--
This message was sent by Atlassian JIRA
(v6.2#6252)
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org