<div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">I had to rely on the fact that the return value of StringTemplate.fragments() is a constant for a callsite, so an implementation detail, otherwise the performance were terrible. Even with that, for the Logger, I was not able to avoid the creation of a StringTemplate when no logging is needed (something which is easy to do with a lambda). So I don't believe a logger based on a template processor makes sense at least not until StringTemplate.Processor.Linkage becomes non-sealed.<br></blockquote><div><br></div><div>I've faced the same issue when experimenting with some StringTemplate Processor implementations: having to rely on the identity of the fragments to be able to uniquely identify a template callsite to be able to cache the expensive resources necessary for the processor (a parsed JSON structure here, but could be any kind of prepared statement for a database, compiled code, pre-populated buffers, etc).<br></div><div><br></div><div>Complex use cases requiring such resource caching are likely to be popular once the API is finalized in a future JDK, which will lead to a bunch of IdentityHashMaps or equivalent over StringTemplate.fragments(). This feels a bit hackish for a brand new API. I understand from the past conversation with Stephen that separating the StringTemplate into a Template and BoundTemplate is likely off the table, but we'll still need a proper way to uniquely identify the callsite. If the identity of StringTemplate.fragments() is the way, then its Javadoc should clearly state that it's constant for a given callsite to permanently set it so that developers can rely upon it as such.</div><div><br></div><div>cheers,</div><div>Michaël</div></div></div>