Well, I can assure you that it should never throw an exception, but yes it will not show what was intended.  Which is similar to the problem of changing types in MessageFormat.  If you change an ID from long to String but don't change from {0,number,integer}, you will get an exception I believe (which won't happen in Anodyzed's TextFormat, it will be silently ignored like the missing method name).  So MessageFormat doesn't give you "type-safety" per se, and even it's parameter number check is done at run-time, not compile-time.<div>

  (*Chris*)<br><br><div class="gmail_quote">On Thu, Aug 2, 2012 at 1:01 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">

Well for the MessageFormatter there can only the number of arguments<br>
greater or smaller than the number of variables meaning {}.<br>
If the number of arguments is smaller, it's not a problem. The message<br>
is perhaps not nice but you don't loose any information.<br>
If the number of arguments is grater, it's a problem, because some of<br>
the arguments will be lost.<br>
I think this can easily fix.<br>
With anodyzed a further problem can occur. You rename person.getName<br>
to person.getLastname(), then the log of [{<a href="http://0.name" target="_blank">0.name</a>}] will become<br>
useless or more worst will throw an exception.<br>
<div class="HOEnZb"><div class="h5"><br>
Niels<br>
<br>
2012/8/2 Chris Pratt <<a href="mailto:thechrispratt@gmail.com">thechrispratt@gmail.com</a>>:<br>
> I'm not sure how you could preserve compiler type-safety with a text<br>
> formatting language.  Can you elaborate?<br>
>   (*Chris*)<br>
><br>
><br>
> On Thu, Aug 2, 2012 at 12:50 PM, niels <<a href="mailto:opensource21@gmail.com">opensource21@gmail.com</a>> wrote:<br>
>><br>
>> Thanks for the explanation. I hope someone has measured that it's really<br>
>> 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>
>> 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>
>> Niels<br>
>><br>
>> 2012/8/2 Chris Pratt <<a href="mailto:thechrispratt@gmail.com">thechrispratt@gmail.com</a>>:<br>
>> > The java.text.MessageFormat is designed to be bi-directional (it parses<br>
>> > as<br>
>> > well as formats), which adds complexity and time.  So there is<br>
>> > 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<br>
>> > 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<br>
>> >> > 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<br>
>> >> > 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,<br>
>> >> > where a<br>
>> >> > formatter was used): If you have formattedMessage("At {} the<br>
>> >> > following error<br>
>> >> > happens", "myMethod", e.getMessage()). So the devoloper has simply<br>
>> >> > forget to<br>
>> >> > add the {} at the messagepattern. Then the really important<br>
>> >> > information is<br>
>> >> > lost. Any change that the MessageFormatter will be changed, so that<br>
>> >> > if<br>
>> >> > L>argArray.length the additional array-information will simply added<br>
>> >> > 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>
><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>