Sent from my iPhone
> On 2016/06/07, at 0:16, Gary Gregory <garydgreg...@gmail.com> wrote:
>
>
> On Jun 6, 2016 6:48 AM, "Remko Popma" <remko.po...@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-unsubscr...@logging.apache.org
> > For additional commands, e-mail: log4j-dev-h...@logging.apache.org
