Thanks for the explanation. I hope someone has measured that it's really faster. The idea of anodyzed is indeed interesting, but my critic on MessageFormatter was that it is not robust enough. So it's possible you loose information. With anodyzed I loose the compiler safeness. So it's definitely not an option.
Can anyone give an answer about my idea of improvement "Any change that the MessageFormatter will be changed, so that if L>argArray.length the additional array-information will simply added at the end?" Niels 2012/8/2 Chris Pratt <[email protected]>: > 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 _______________________________________________ slf4j-user mailing list [email protected] http://mailman.qos.ch/mailman/listinfo/slf4j-user
