I'm not sure how you could preserve compiler type-safety with a text formatting language.  Can you elaborate?<div>  (*Chris*)<br><br><div class="gmail_quote">On Thu, Aug 2, 2012 at 12:50 PM, niels <span dir="ltr"><<a href="mailto:opensource21@gmail.com" target="_blank">opensource21@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Thanks for the explanation. I hope someone has measured that it's really faster.<br>
The idea of anodyzed is indeed interesting, but my critic on<br>
MessageFormatter was that it is not robust enough. So it's possible<br>
you loose information. With anodyzed I loose the compiler safeness. So<br>
it's definitely not an option.<br>
<br>
Can anyone give an answer about my idea of improvement "Any change<br>
<div class="im">that the MessageFormatter will be changed, so that if<br>
L>argArray.length the additional array-information will simply added<br>
at the end?"<br>
</div>Niels<br>
<br>
2012/8/2 Chris Pratt <<a href="mailto:thechrispratt@gmail.com">thechrispratt@gmail.com</a>>:<br>
<div class="HOEnZb"><div class="h5">> The java.text.MessageFormat is designed to be bi-directional (it parses as<br>
> well as formats), which adds complexity and time.  So there is definitely<br>
> room for improvement in the performance.  Both Ceki's {} processing and<br>
> Onyx's processing (whose format is extended directly from the<br>
> java.text.MessageFormat) are uni-directional formatters that are developed<br>
> for speed.<br>
>   (*Chris*)<br>
><br>
><br>
> On Thu, Aug 2, 2012 at 9:31 AM, niels <<a href="mailto:opensource21@gmail.com">opensource21@gmail.com</a>> wrote:<br>
>><br>
>> My question is, why the internal implementation doesn't use the<br>
>> standard-formatter class. Can't see any argument in<br>
>> logging_performance.<br>
>> Niels<br>
>><br>
>> 2012/8/2 Roman Muntyanu <<a href="mailto:rmuntyan@softserveinc.com">rmuntyan@softserveinc.com</a>>:<br>
>> >>> Furthermore I wonder what are the reasons that you don't use the<br>
>> >>> Formatter-class of the JDK which has more possibilities.<br>
>> > Because of <a href="http://www.slf4j.org/faq.html#logging_performance" target="_blank">http://www.slf4j.org/faq.html#logging_performance</a><br>
>> ><br>
>> > -----Original Message-----<br>
>> > From: <a href="mailto:slf4j-user-bounces@qos.ch">slf4j-user-bounces@qos.ch</a> [mailto:<a href="mailto:slf4j-user-bounces@qos.ch">slf4j-user-bounces@qos.ch</a>] On<br>
>> > Behalf Of niels<br>
>> > Sent: Thursday, August 02, 2012 12:55 PM<br>
>> > To: <a href="mailto:slf4j-user@qos.ch">slf4j-user@qos.ch</a><br>
>> > Subject: [slf4j-user] Questions about formattedMessage<br>
>> ><br>
>> > Hi<br>
>> > I restart thinking about to create a fluid-log-facade for java. The idea<br>
>> > is to write log.onError().aMessage("test") or<br>
>> > log.onDebug().aParmameter("param").withValue(1). One idea is to have<br>
>> > something like formattedMessage("A {} test", "small"). I see that slf4j has<br>
>> > something similar.<br>
>> > Unfortunately I found the the implementation not reliable enough. The<br>
>> > problem is the following situation (I had in real-life last year, where a<br>
>> > formatter was used): If you have formattedMessage("At {} the following error<br>
>> > happens", "myMethod", e.getMessage()). So the devoloper has simply forget to<br>
>> > add the {} at the messagepattern. Then the really important information is<br>
>> > lost. Any change that the MessageFormatter will be changed, so that if<br>
>> > L>argArray.length the additional array-information will simply added at the<br>
>> > end?<br>
>> ><br>
>> > Furthermore I wonder what are the reasons that you don't use the<br>
>> > Formatter-class of the JDK which has more possibilities.<br>
>> ><br>
>> > Best regards<br>
>> > Niels<br>
>> > _______________________________________________<br>
>> > slf4j-user mailing list<br>
>> > <a href="mailto:slf4j-user@qos.ch">slf4j-user@qos.ch</a><br>
>> > <a href="http://mailman.qos.ch/mailman/listinfo/slf4j-user" target="_blank">http://mailman.qos.ch/mailman/listinfo/slf4j-user</a><br>
>> > _______________________________________________<br>
>> > slf4j-user mailing list<br>
>> > <a href="mailto:slf4j-user@qos.ch">slf4j-user@qos.ch</a><br>
>> > <a href="http://mailman.qos.ch/mailman/listinfo/slf4j-user" target="_blank">http://mailman.qos.ch/mailman/listinfo/slf4j-user</a><br>
>> _______________________________________________<br>
>> slf4j-user mailing list<br>
>> <a href="mailto:slf4j-user@qos.ch">slf4j-user@qos.ch</a><br>
>> <a href="http://mailman.qos.ch/mailman/listinfo/slf4j-user" target="_blank">http://mailman.qos.ch/mailman/listinfo/slf4j-user</a><br>
><br>
><br>
><br>
> _______________________________________________<br>
> slf4j-user mailing list<br>
> <a href="mailto:slf4j-user@qos.ch">slf4j-user@qos.ch</a><br>
> <a href="http://mailman.qos.ch/mailman/listinfo/slf4j-user" target="_blank">http://mailman.qos.ch/mailman/listinfo/slf4j-user</a><br>
_______________________________________________<br>
slf4j-user mailing list<br>
<a href="mailto:slf4j-user@qos.ch">slf4j-user@qos.ch</a><br>
<a href="http://mailman.qos.ch/mailman/listinfo/slf4j-user" target="_blank">http://mailman.qos.ch/mailman/listinfo/slf4j-user</a><br>
</div></div></blockquote></div><br></div>