String Templates Question - are expressions within a TemplateString literal evaluated immediately, or when a template is applied?

[Jim Laskey]

On Sep 22, 2022, at 11:08 AM, Nathan Walker <nathan.h.walker at gmail.com<mailto:nathan.h.walker at gmail.com>> wrote:

Hi folks,

Question regarding TemplateStrings that I could not seem to find the answer to in the JEP write up or the Javadoc for TemplateString:  Is the expression evaluation lazy, or immediate?

In other words, if I do something like this:

     List<Integer> list=new ArrayList<>();
     TemplateString ts = "size = \{list.size()}"
     list.add(1);
     System.out.println(ts.apply(STR));

Will it print out size = 0, or size = 1?

The expression is evaluated and the value is captured when creating the TemplatedString instance. There is some discussion around left to right evaluation that tries to clarify this. So the answer is “size = 0”.



My main reason for asking is that I would love for string templates to result in logging interfaces with overloaded methods that can take TemplateStrings instead of strings, and which are only evaluated if the log level is enabled.  So that instead of something like this:

     if (logger.isEnabled(Level.DEBUG)) {
          logger.log(Level.DEBUG, "Expensive value is " + lookup() );
     }

we can just do:

     log.log(Level.DEBUG, "Expensive value is \{lookup()}");

And be confident that the cost of invoking lookup() will only be paid if DEBUG is enabled.

Probably over 80% of the string building I have seen over my career has been related to building log messages.  And the mistakes I have most often seen are:

     1. Expensive message construction not guarded by checking if logging is enabled at that level
     2. Expensive message construction guarded, but by checking the *wrong* logging level (e.g. check INFO, log at ERROR)
     3. Using some sort of parameterized message/string format but getting the parameters wrong (out of order, missing one, having too many, etc.)

If TemplateStrings evaluate their expression fragments only when processed then every one of these problems gets addressed, and logging code becomes *a lot* simpler to read, write, and code review.

(Random side note: I *love* the choice of \ instead of $.  It took some time for me to get use to the idea, but keeping the same escape character is fantastic and I wish more languages had done that instead of using $)

You can play some tricks with Suppliers or Futures + lambdas to get lazy evaluation. I have an roughed out (i.e., old) example at https://cr.openjdk.java.net/~jlaskey/templates/examples/Log.java

Cheers,

— Jim




Thanks for your time,
Nathan
--
Nathan H. Walker
nathan.h.walker at gmail.com<mailto:nathan.h.walker at gmail.com>
(703) 987-8937



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20220922/d604131e/attachment-0001.htm>