logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Remko Popma <remko.po...@gmail.com>
Subject Re: Garbage-free Log4j docs preview
Date Mon, 06 Jun 2016 21:50:51 GMT


Sent from my iPhone

> On 2016/06/07, at 0:16, Gary Gregory <garydgregory@gmail.com> wrote:
> 
> 
> On Jun 6, 2016 6:48 AM, "Remko Popma" <remko.popma@gmail.com> wrote:
> >
> >
> >
> > On Monday, June 6, 2016 at 6:16:52 PM UTC+9, Anthony Maire wrote:
> >>
> >> Hi Remko
> >>
> >> Great job ! 
> >> As Martin said, it's really a good thing for the high-performance community
that someone is trying to improve existing logging frameworks.
> >> The company I'm working for even started to write it's own custom SLF4J implementation,
and now we are evaluating if it's better for us to finish this internal project or to write
some custom filters and switch to log4j.
> >
> > Would you like to hear my totally unbiased opinion/advice? :-)
> > I'm not a fan of SLF4J... It means you can never use the rich feature set of the
underlying logger. Like no lambdas! No CharSequences or plain domain objects, only Strings.
> > Not sure why people would want to use it in enterprise software. 
> > Maybe, well, likely, I'm biased :-) but I honestly don't see the advantage.
> > If the concern is the ability to change your mind later, there is always the log4j-to-slf4j
adapter...
> >  
> >>
> >>
> >> I think there is one possible improvement with boxed primitive types: for the
moment we want to use only SLF4J api (as a consequence, we're aiming for a low allocation
rate, but not necessarily no allocation at all), so the "Unboxer" mecanism provided in log4j
is not an option for us to deal with primitive types.
> >> Is this possible in a future release to have a special cases in ParameterFormatter.appendSpecialTypes()
for boxed primitive types ? Currently, when using parametrized message with both Object and
primitive parameters, I haven't find a "SLF4J-compatible" way to avoid this allocation when
formatting.
> >
> >
> > If I understand correctly, you're less concerned with the varargs and the auto-boxed
primitives, but would like to avoid calling toString() on the objects that resulted from the
auto-boxing (please correct me if I misunderstood). Is something like the below what you have
in mind? Would you mind raising a feature request on the Log4j2 issue tracker for this?
> >
> > private static boolean appendSpecialTypes(final Object o, final StringBuilder str)
{
> >
> >     ...
> >     } else if (o instanceof Long) {
> >         str.append(((Long) o).longValue());
> >         return true;
> >
> >     } else if (o instanceof Integer) {
> >         str.append(((Integer) o).intValue());
> >
> >         return true;
> >
> >     } else if (o instanceof Double) {
> >         str.append(((Double) o).doubleValue());
> >
> >         return true;
> >     } // similarly for float, short and boolean.
> >     ...
> >
> > }
> 
> How about a map lookup to a code instead of a cascading if-else? Or... switch to Java
8 ;-)
> 
I don't understand the Java 8 idea: does Java 8 have some mechanism that this code can be
written differently?

Shall we discuss further on the Jira?
https://issues.apache.org/jira/browse/LOG4J2-1415

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

Mime
View raw message