JEP 430: String Templates Mandatory TemplateProcessor

[Jim Laskey]

I’ve mentioned this previously, while not impossible it is difficult to switch simply because the context of detecting processor dot is at the parser level, where the detection of \{ is at the lexer/tokenization level.

There is a big plus for not following the herd with ${, you can embed other languages such as JavaScript without fear of conflict. \{ also doesn’t conflict with existing templating libraries.

In a previous email, I demonstrated how you could use your own style StringTemplates using ${.

Note that there is a very strong backlash against the backslash (play on words intended) in the Java community.

Depends on who you hang out with. I know the Swift crowd seem content with \(. Not sure I see the point of making all languages the same.

Like any new language feature, you do get use to \{. Once IDEs integrate, string templates will become second nature.

Cheers,

— Jim

📱

On May 13, 2023, at 11:22 AM, interlink.sg7 at gmail.com wrote:


Hello,
I tried out the early-access build of JDK 21 and saw that the TemplateProcessor seems to be mandatory now for String Templates:

    var hello = "Hello \{name}"; ==> error: processor missing from template expression

The JEP says: "Thus if we forget to use a template processor such as STR, RAW, or FMT then a compile-time error is reported".

I know you dread this kind of discussion, but if that is the case, would we now be able to reconsider ${…}?
The original reason behind \{…} was to avoid conflicts with legacy code.
Using ${…} would require a tag on string templates (either a prefix or a delimiter other than "). See Alternatives section in the JEP.
However if the TemplateProcessor . TemplateArgument is mandatory it kinda acts as a tag anyway?
Backwards compatibility is still ensured as far as I can tell.

Note that there is a very strong backlash against the backslash (play on words intended) in the Java community.

Kind regards,

Simon


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