Mailing-List: contact log4j-dev-help@logging.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Log4J Developers List" <log4j-dev@logging.apache.org>
Date: Sat, 8 Aug 2015 05:10:46 +0000 (UTC)
From: "Ralph Goers (JIRA)" <jira@apache.org>
To: log4j-dev@logging.apache.org
Message-ID: <JIRA.12707304.1397001509000.11856.1439010646444@Atlassian.JIRA>
In-Reply-To: <JIRA.12707304.1397001509000@Atlassian.JIRA>
References: <JIRA.12707304.1397001509000@Atlassian.JIRA>
 <JIRA.12707304.1397001509188@arcas>
Subject: [jira] [Commented] (LOG4J2-599) Support lambda functions (or
 similar) for log message parameters
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Ralph Goers commented on LOG4J2-599:
------------------------------------

I just looked at the branch and am struggling a little bit with what I see - it doesn't strike me as really supporting Java 8 or Java Lambdas, but instead allows the lambda syntax to be used . I would think to be complete we would need methods that accept at least Supplier, Function, Predicate, although java.util.logging.Logger only supports Supplier.

On another note, how will the log4j-jul Logger deal with the Supplier? Will it resolve the result there or pass the Supplier along (which it can't do if we use a Callable). To support the new methods we will either have to create a new log4j-jul8 module or use reflection tricks to support them.

> 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