Update on String Templates (JEP 459)

[Alex Buckley]

Given that few APIs will take StringTemplate on Day 1, I've been 
wondering how people will approach making string templates interoperate 
with APIs that only take String. They'll try the converts-to-String 
functionality of + --  "" + <<string template>>  -- and find it's a dead 
end.

BTW, it's always been true that there's no empty template literal, but 
with the removal of template processors there will be more "standalone" 
StringTemplate variables, and this will be a common error:

StringTemplate st = "";  // Error, can't assign String to StringTemplate


I also wondered if it could ever mean anything to compose two string 
templates with +. It feels similar to embedding a string template in a 
template literal. If the two templates being composed are in the same 
"language" then perhaps the Java language could help combine them.

Alex

On 3/11/2024 1:47 PM, Jim Laskey wrote:
> String plus isn’t needed. Just as templates remove the need for string plus, the combining of string templates and strings can be done with nested embedded expressions.
> 📱
> 
>> On Mar 11, 2024, at 5:25 PM, Alex Buckley <alex.buckley at oracle.com> wrote:
>>
>> On 3/11/2024 10:36 AM, Brian Goetz wrote:
>>> Overall, though, I am not so enthused about creating yet another new lexical mechanism for having different kinds of stringy things.
>> All strings -- not just string literals, and not just constant expressions of type String -- can be composed with +. Is there an equivalent composition operator for string templates? (That is, all values of type StringTemplate, not just template literals.)
>>
>> I ask because the more lexical similarity between a template literal and a string literal, the more I think people will try to use + with two template literals, or with one template literal and one string literal. AIUI the result will be a surprise:
>>
>> String s = "Hello" + "\{x}";
>>   // Second operand to + undergoes string conversion a.k.a. toString()
>> print(s);  // Hello0x12345678
>>
>> Alex