String template interpolation as a two steps process

[forax at univ-mlv.fr]

----- Original Message -----
> From: "Ron Pressler" <ron.pressler at oracle.com>
> To: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "Brian Goetz" <brian.goetz at oracle.com>, "amber-spec-experts" <amber-spec-experts at openjdk.java.net>
> Sent: Thursday, April 4, 2024 5:24:01 PM
> Subject: Re: String template interpolation as a two steps process

>> On 4 Apr 2024, at 15:31, forax at univ-mlv.fr wrote:

Hi Ron,

>> 
>> 
>> In the past, due to the fact that an interface was used for the processor, it
>> was hard, not impossible, but hard, to provide a good api without adding
>> security issues to the platform (the Lookup object being transfered to the
>> string template processor). With the new design, I think we can provide a
>> better API to the library implementors, not a priviledged API like only the JDK
>> can use but a better API that the one currently proposed.
> 
> Yes — assuming you mean some non-privileged mechanism for caching parsing
> results — but that shouldn’t necessarily be in the first preview of the new
> design. It is a performance optimisation that can be postponed until we’re sure
> we’re on the right track from the perspective of the consumer.

The idea of the API is that instead of taking a StringTemplate as parameter, the StringTemplate is splitted into two parts,
the fragments part is used to create a cacheable object and then the template processor method takes both the cacheable objet and the live values as arguments.
  
So
  process($" ... \{value1} ... \{value2} ")

is transformed to
  var template = StringTemplate.of(fragments);
  var cachedObject = CachedObject.of(template);
  process(cachedObject, value1, value2))

I agree that there is not enough time to implement that new API in 23.

And i can write a bytecode rewriter that patch the bytecode generated for Java 23 to go through an invokedynamic that will do the caching so we get a good idea of what the compiler should generate and what the bootstrap method should do. I'm a little worry about the stacktrace we expose when the cached object is initialized.

> Writing good
> template processors is an interesting and challenging aspect done by “template
> processing professionals” (e.g. see what’s required of proper HTML template
> processing:
> https://rawgit.com/mikesamuel/sanitized-jquery-templates/trunk/safetemplate.html)
> and there’s much for library authors to digest before considering caching (even
> though it may become an issue later on).

It's for PHP and PHP templates are far more complex that Java string templates, for example, PHP allows {if} ... {else}.

> 
> — Ron

Rémi