[
https://issues.apache.org/jira/browse/LOG4J2-599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14679329#comment-14679329
]
Jukka Nikki edited comment on LOG4J2-599 at 8/9/15 8:51 PM:
------------------------------------------------------------
It seems that response to question "How would you do it if Java 8 was our
requirement instead of 7?" was only a part of story.
First, Java8 gives possibility to use Default Methods, so it could be possible
to make changes to Logger interface without changing any implementation classes
-- which in turn wouldn't broke custom implementations or implementations that
depend on existing abstract classes.
Otherwise if Java 8 could be used it would be wise to use existing Supplier
where applicable and implement just those extra supplier variants which are
needed (MessageSupplier being currently only one found) -- now, sadly enough,
there might be need for custom int, long and double log4j suppliers also to be
java8 compatible. This is up to how current Log4J methods are defined, if they
don't use native types int, long and double variants are not needed.
https://docs.oracle.com/javase/8/docs/api/java/util/function/IntSupplier.html
To note: Current Guava users which convert to Java 8 have at least two
problematic classes: Optional and Objects - both exist for Java 8 and Guava.
These problems arise especially if wildcard imports have been used. And sure:
they have been used often since Eclipse let's this type of imports to be
default to which organize import converts import definitions. Now, if Log4J
util package is imported thru wildcard import and java8 code uses Supplier
classes imports collide. For this reason I would try to find other name instead
of using java 8 names directly (MessageSuppier could be here good example, so
other names could be like "ParameterSupplier" if providing parameters is main
use case and if it's important to find names which are close to java8 but not
exactly same)
Removed discussion of naming :D Too much of it already.
was (Author: nikkijuk):
It seems that response to question "How would you do it if Java 8 was our
requirement instead of 7?" was only a part of story.
First, Java8 gives possibility to use Default Methods, so it could be possible
to make changes to Logger interface without changing any implementation classes
-- which in turn wouldn't broke custom implementations or implementations that
depend on existing abstract classes.
Otherwise if Java 8 could be used it would be wise to use existing Supplier
where applicable and implement just those extra supplier variants which are
needed (MessageSupplier being currently only one found) -- now, sadly enough,
there might be need for custom int, long and double log4j suppliers also to be
java8 compatible. This is up to how current Log4J methods are defined, if they
don't use native types int, long and double variants are not needed.
https://docs.oracle.com/javase/8/docs/api/java/util/function/IntSupplier.html
To note: Current Guava users which convert to Java 8 have at least two
problematic classes: Optional and Objects - both exist for Java 8 and Guava.
These problems arise especially if wildcard imports have been used. And sure:
they have been used often since Eclipse let's this type of imports to be
default to which organize import converts import definitions. Now, if Log4J
util package is imported thru wildcard import and java8 code uses Supplier
classes imports collide. For this reason I would try to find other name instead
of using java 8 names directly (MessageSuppier could be here good example, so
other names could be like "ParameterSupplier" if providing parameters is main
use case and if it's important to find names which are close to java8 but not
exactly same)
BTW: Without wanting to start long debate on issue I find LazyLogger and
Logger2 almost as bad names, and even if I don't like LambdaLogger or
Java8Logger too much I'd prefer (currently) Java8Logger IF ONLY REASON to have
Logger2 is to provide java8 support and stay backward compatible. Actually,
IMO: All other names than Logger are not really good and Java8Logger would be
to me only a solution for limited time (2.X).
> 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]
