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 "Remko Popma (JIRA)" <ji...@apache.org> on 2015/08/05 15:59:05 UTC

[jira] [Commented] (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=14658248#comment-14658248 ] 

Remko Popma commented on LOG4J2-599:
------------------------------------

I like Jason's idea. I experimented a little and it seems to work.

Nick's idea to use the existing {{log(String, Object...)}} methods does not seem to work. The following simple client program did not compile:
{code}
// Does not compile with our current Logger API: Eclipse complains that
// "The method trace(String, Object...) in the type Logger is not applicable for the arguments (String, () -> {})"
logger.trace("Expensive parameter {}", () -> new SecureRandom().nextLong());
{code}

An alternative is to add corresponding  {{log(String, Callable<?>...)}} methods. This solves the compilation problem. It also means that clients cannot mix lambda parameters with object parameters: clients need to provide either all objects or all lambda expressions as parameters. (Sounds reasonable to me.)

I propose adding the following methods to the {{Logger}} API:
* trace(Marker, Callable<?>)
* trace(Marker, Callable<?>, Throwable)
* trace(Marker, String, Callable<?>...)
* trace(Callable<?>)
* trace(Callable<?>, Throwable)
* trace(String, Callable<?>...) 
* ... same for all other log levels

Client code using Java 6 or 7 would work unchanged (unlikely they will use these new methods):
{code}
// client code using Java 6 or 7 would continue to use this style
if (logger.isDebugEnabled()) {
   logger.debug("I am expensive to compute {}", someExpensiveMethodCall();
}
{code}

and users on Java 8 now have the option to replace the above with a single lambda expression:
{code}
// client code using Java 8 can use a lambda expression,
// no longer needing to check if the DEBUG level is enabled
logger.debug("I am expensive to compute {}", () -> someExpensiveMethodCall();
{code}

Thoughts?

> 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
>              Labels: Java8
>
> 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.3.4#6332)

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