Presentation at JCrete.org

[Michaël Figuière]

>
> 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.
>

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).

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.

cheers,
Michaël
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20230711/b96036ed/attachment.htm>