The java.text.MessageFormat is designed to be bi-directional (it parses as
well as formats), which adds complexity and time. So there is definitely
room for improvement in the performance. Both Ceki's {} processing and
Onyx's processing (whose format is extended directly from the
java.text.MessageFormat) are uni-directional formatters that are developed
for speed.
(*Chris*)
On Thu, Aug 2, 2012 at 9:31 AM, niels <[email protected]> wrote:
> My question is, why the internal implementation doesn't use the
> standard-formatter class. Can't see any argument in
> logging_performance.
> Niels
>
> 2012/8/2 Roman Muntyanu <[email protected]>:
> >>> Furthermore I wonder what are the reasons that you don't use the
> Formatter-class of the JDK which has more possibilities.
> > Because of http://www.slf4j.org/faq.html#logging_performance
> >
> > -----Original Message-----
> > From: [email protected] [mailto:[email protected]] On
> Behalf Of niels
> > Sent: Thursday, August 02, 2012 12:55 PM
> > To: [email protected]
> > Subject: [slf4j-user] Questions about formattedMessage
> >
> > Hi
> > I restart thinking about to create a fluid-log-facade for java. The idea
> is to write log.onError().aMessage("test") or
> log.onDebug().aParmameter("param").withValue(1). One idea is to have
> something like formattedMessage("A {} test", "small"). I see that slf4j has
> something similar.
> > Unfortunately I found the the implementation not reliable enough. The
> problem is the following situation (I had in real-life last year, where a
> formatter was used): If you have formattedMessage("At {} the following
> error happens", "myMethod", e.getMessage()). So the devoloper has simply
> forget to add the {} at the messagepattern. Then the really important
> information is lost. Any change that the MessageFormatter will be changed,
> so that if L>argArray.length the additional array-information will simply
> added at the end?
> >
> > Furthermore I wonder what are the reasons that you don't use the
> Formatter-class of the JDK which has more possibilities.
> >
> > Best regards
> > Niels
> > _______________________________________________
> > slf4j-user mailing list
> > [email protected]
> > http://mailman.qos.ch/mailman/listinfo/slf4j-user
> > _______________________________________________
> > slf4j-user mailing list
> > [email protected]
> > http://mailman.qos.ch/mailman/listinfo/slf4j-user
> _______________________________________________
> slf4j-user mailing list
> [email protected]
> http://mailman.qos.ch/mailman/listinfo/slf4j-user
>
_______________________________________________
slf4j-user mailing list
[email protected]
http://mailman.qos.ch/mailman/listinfo/slf4j-user
