Update on String Templates (JEP 459)

[Brian Goetz]

> Well, we can start by first examining the methods of the 
> StringTemplate interface in JDK 22:
>
> I reckon we still need the factories and accessors.

I would like to question the "factories" part of that.  As Ron has 
pointed out, having string / string template literals be the sole source 
of fragments in STs preserves a valuable non-tainting property.  (Remi 
has expressed reasonable concerns that we will not be able to preserve 
this property in the end, but it is worth trying.)   This is part of the 
motivation for `combine`; preserving this safety invariant as well as 
providing a convenient operation.

> As for string interpolation, the first one (indicated by *) is on 
> Brian’s list, and I am not sure we need the second, static one: is it 
> not equivalent to `StringTemplate.of(frags, vals).interpolate()`? Is 
> it there just to avoid allocating a StringTemplate, or perhaps to 
> support the implementation of the instance method `interpolate()`?

There is a performance aspect to this.  The details vary from the 
initial version that we previewed previously to the latest proposal, but 
the essence is the same: if we can tie a string template instance to its 
point of capture in the source code, then we can cache a method handle 
that has full knowledge of the template fragments and the embedded 
expression types to optimize the conversion.  If the same capture site 
captures a template with different embedded expressions (such as code in 
a loop, or the toString method of some object that uses templates), we 
can reuse that MH.  There are many possible optimizations here (and even 
more for a complex processor like FMT, that has to do a lot of work when 
scanning the format string.)

If a ST has its origin in an actual capture site, as a ST literal does, 
then we have a place to cache this.  The current design uses the 
invokedynamic linkage state, but there are other possible places too.  
Calling `StringTemplate.of(frags, vals).interpolate()` has no such place 
to cache the analysis of the constant parts (fragments and expressions 
types.)

> I am not sure why this static `toString` method is there, rather than 
> relying on the `toString()` instance method that every object must 
> support. Is it present to support the implementation of the instance 
> method? I guess I don’t see why this is not just a `default` 
> implementation of the instance method.

I think that's right (Jim might have some context here.)