On Mon, Jun 6, 2016 at 2:50 PM, Remko Popma <[email protected]> wrote:
> > > Sent from my iPhone > > On 2016/06/07, at 0:16, Gary Gregory <[email protected]> wrote: > > > On Jun 6, 2016 6:48 AM, "Remko Popma" <[email protected]> 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 > Commenting in JIRA then :-) ... Gary > > > > > > >> > >> Kind Regards, > >> Anthony > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > -- E-Mail: [email protected] | [email protected] Java Persistence with Hibernate, Second Edition <http://www.manning.com/bauer3/> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> Spring Batch in Action <http://www.manning.com/templier/> Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
