[
https://issues.apache.org/jira/browse/LOG4J2-599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14679375#comment-14679375
]
Ralph Goers edited comment on LOG4J2-599 at 8/9/15 10:08 PM:
-------------------------------------------------------------
I think I gave estimates for when I would be OK moving to Java 8 and it isn't
any time soon. We had someone ask about one of the fixes going in to 2.4 that
he won't be able to have because they are still on Java 6. I'm quite sure
there are a lot of systems out there running Java 7. I have no interest in
eliminating them as users.
That said, we always want to take advantage of features in new JDKs as we can.
If you look at the way Remko implemented the support, LambdaLogger was an
interface but he was able to add all the methods to AbstractLogger - so the
only different between getLambdaLogger and getLogger was the interface they
returned. However, wouldn't it make more sense to implement LogManager just as
{code}
public static <T extends Logger> T getLogger(final Class<?> clazz) {
final Class<?> cls = callerClass(clazz);
return (T) getContext(cls.getClassLoader(),
false).getLogger(cls.getName());
}
{code}
This should suffice no matter what the interface is since AbstractLogger is
implementing all of them. If you do this then the user should just be able to
declare the variation of Logger that they are expecting.
was (Author: [email protected]):
I think I gave estimates for when I would be OK moving to Java 8 and it isn't
any time soon. We had someone ask about one of the fixes going in to 2.4 that
he won't be able to have because they are still on Java 6. I'm quite sure
there are a lot of systems out there running Java 7. I have no interest in
eliminating them as users.
That said, we always want to take advantage of features in new JDKs as we can.
If you look at the way Remko implemented the support, LambdaLogger was an
interface but he was able to add all the methods to AbstractLogger - so the
only different between getLambdaLogger and getLogger was the interface they
returned. However, wouldn't it make more sense to implement LogManager just as
{code}
public static <T extends Logger> T getLogger(final Class<?> clazz) {
final Class<?> cls = callerClass(clazz);
return (T) getContext(cls.getClassLoader(),
false).getLogger(cls.getName());
}
{code}
This should suffice no matter what the interface is since AbstractLogger is
implementing all of 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
> Assignee: Remko Popma
> Priority: Minor
> Labels: Java8
> Fix For: 2.4
>
>
> 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: [email protected]
For additional commands, e-mail: [email protected]
