Well for the MessageFormatter there can only the number of arguments
greater or smaller than the number of variables meaning {}.
If the number of arguments is smaller, it's not a problem. The message
is perhaps not nice but you don't loose any information.
If the number of arguments is grater, it's a problem, because some of
the arguments will be lost.
I think this can easily fix.
With anodyzed a further problem can occur. You rename person.getName
to person.getLastname(), then the log of [{0.name}] will become
useless or more worst will throw an exception.Niels 2012/8/2 Chris Pratt <[email protected]>: > 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 _______________________________________________ slf4j-user mailing list [email protected] http://mailman.qos.ch/mailman/listinfo/slf4j-user
