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 ;-)
>
>
>>
>> Kind Regards,
>> Anthony
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
> For additional commands, e-mail: log4j-dev-h...@logging.apache.org
