Type parameters and other topics regarding String Templates

Johannes Spangenberg johannes.spangenberg at hotmail.de
Sun Oct 29 01:16:16 UTC 2023


Hello, I recently thought about String Templates and just read the new 
JEP 459 for the second preview. I have four comments about the current 
JEP, more or less ordered by importance.

*1) Unusual generic types for exceptions and return values*

The generic types as specified by JEP 459 look like remnants to me. 
Since template expressions are syntactic sugar for method calls, we 
should just use the type of the process method, as was introduced by 
this JEP. However, the generic types were somehow left in the JEP. Is 
there a good reason for that?

For example, java.lang.AutoCloseable does not have a generic type for 
the exception. The only advantage I see is that you can implement 
processors using Lambdas without introducing a functional interface. How 
often do you have a processor that is trivial enough that you see the 
benefit of using a lambda? Even the implementation of STR takes multiple 
lines. If somebody needs a functional interface, it is trivial to create 
one yourself.

In my opinion, the noise introduced by the template parameters greatly 
overshadows the advantage of lambdas without having to declare a 
functional interface first.

For RAW, STR, and FMT, you may either introduce a sub-interface without 
the generic exception or just implement them within their own class 
outside java.lang.

*2) Generic type for embedded expressions*

While I don't see the value of the existing type parameters, I think it 
would be helpful to have a generic type for the embedded expressions. In 
contrast to the existing type parameters, such a type parameter would 
extend the capabilities. It would be possible to have type-safe inputs 
for processors, which is not possible with the current JEP.

    public interface StringTemplate<T>
         ...
         public interface Processor<T> {
             Object process(StringTemplate<? extends T> st) throws Throwable;
         }
         ...
    }

*3) Let STR and FMT keep the indentation
*

I was wondering if STR and FMT should keep the intention when the 
arguments contain line breaks. Most usages are probably not indented or 
only use arguments without line breaks. However, whenever I encountered 
a situation where I wanted to insert a multiline string into an indented 
line, I always wanted to keep the intention. A potential implementation 
could basically copy all the whitespace characters directly after the 
most recent line break in the fragments and insert them behind each line 
break of the template argument.

    String multilineString = """
         First line.
         Second line.
         """;
    System.out.println("""
         Output:

             \{multilineString}

         ...
         """);

I have to say I am myself a bit skeptical as this would noticeably 
increase the complexity. However, I cannot think of a scenario where you 
don't want this to happen. (I could imagine that I would otherwise 
implement such a processor in almost all my projects and end up never 
using STR.)

*4) Purpose of StringTemplate.interpolate()?*

And finally, although not very important, I am wondering about the 
usefulness of StringTemplate.interpolate. In the rare case when you 
actually need this functionality, you can also call 
STR.process(template). There is also template.process(STR) for some reason.

For toString()-like use cases, we already have 
StringTemplate.toString(StringTemplate). I don't think that 
StringTemplate.interpolate() would be a good fit in such cases. And 
again, you can otherwise still call STR.process(...).


That was all. I am happy for any reply.

PS: I find it interesting that the JEP does not mention tagged templates 
of JavaScript, although the concepts look quite similar.

Best Regards,
Johannes
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20231029/59483f56/attachment.htm>


More information about the amber-dev mailing list