I'm not sure how you could preserve compiler type-safety with a text formatting language. Can you elaborate? (*Chris*)
On Thu, Aug 2, 2012 at 12:50 PM, niels <[email protected]> wrote: > 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 >
_______________________________________________ slf4j-user mailing list [email protected] http://mailman.qos.ch/mailman/listinfo/slf4j-user
