JEP Draft: String Templates (Final) | Hacker News Reader

JEP Draft: String Templates (Final)

openjdk.org

19 pointsmfiguiere12 comments

Even after reading this proposal over the past months over and over in all its iterations, I still don't get it. Is this what many developers want? I fear people will just stick with +concatenation because it's less verbose than this.

STR.”what is so bad about \{this}?”

`"what is so bad about" + this` uses 4 less characters, and that includes the spaces around the plus.

Except it’s more if I have text following a variable.

Try this:

    STR.”x=\{x} y=\{y} z=\{z}.”

Compared to:

    “x=“ + x + “ y=“ + y + “ z=“ + z + “.”

A string template incurs an overhead of 3 characters per variable (“\“, “{“, and “}”) plus the leading “STR.”, which is 4 characters. Concatenation incurs an overhead of 4 non-whitespace characters per variable (`”+` and `+”`), and that’s ignoring whitespace. If you have more than 3-4 variables, string templates are shorter.

The concatenation example is less readable as well. Have I included whitespace to exactly match the string template example? It’s a little hard to tell at a glance because I have to distinguish what is code whitespace and what’s included in the string.

You may have a point for strings. But this is about guarantees for more convoluted expressions in other languages. If you include validating SQL being injection-free, this is waaay less verbose.

Also this is about enabling a _system_ of templating, and potentially letting the IDE treat it as such and warn you at compile-time. Small snippets tend to creep all over a codebase. Some use-case that this enables:

* HTML templating React-server-side-style: response.send(HTML_PART."""<div>\{name}</div>"""). Here both the HTML is validated, and the variable is escaped; at compile-time. How do you beat this?

* Query-building: businessFilterClause.add(WHERE_VALIDATE."""PRODUCT_MODEL IN \{authorizedModels}"""). And at compile-time or build-time having it validated against a database schema, and the compatibility of your types.

F-strings have been the fastest ever adopted syntax change to Python, and is the overall most popular of the recent post-3.6 additions. That’s Python, but it shares similarities with Java in terms of numerous different ways of formatting strings.

They are very, very useful, but lots of people said similar things to you about not getting it. Then… they used them, I guess. \{} is not very verbose either, and the use of generic formatters is a really nice addition.

I'm always happy to have stuff like f-strings in languages. This on the other hand feels much too overladen with separate requirements of safety/etc. which reduces its general usability. Suddenly you don't have to prefix it with "f" / "{}" but "STR." and "\{}", which (unlike f-strings) keeps cluttering your reading space more, something you actually try to improve on with this very feature in other languages. Neither the prefix nor the curly braces are optional for simple terms sadly, unlike in some other languages.

I have read the explanation by various members of the OpenJDK team as to why that syntax was chosen and I still don't understand it. Even Brian's explanation, which otherwise gets right through to me even on more complex topics, did not really clarify it for me. He says choosing ${} would have made all the existing Strings a template if they contain ${} with a valid variable in the same scope, which breaks compatibility.

But I don't know what I am missing to not see the breakage. For an existing String literal having a ${...} does not make it into a template that will be processed. You have to explicitly invoke STR. on that to process it as a template. Else if will be just like any other String with no interpolation. STR. is a completely new feature and is illegal in prior versions so I don't see how this breaks compatibility.

Even if you had a variable named STR in existing code, it is illegal to do STR."some str literal".

I guess it is too late now.

It's nice that they implemented string templates essentially exactly the same way Javascript template literals and tag functions work. They even give an example of using it to create a prepared statement (e.g. DB."SELECT * FROM foo WHERE bar = \{inputParam}") which is exactly what many NodeJS libraries due, e.g. Slonik https://github.com/gajus/slonik, like sql`SELECT * FROM foo WHERE bar = ${inputParam}`;

Not quite. Dedenting template literal is a pain in the ass, which should have been supported from day one.

The TC39 committee actually come up with an additional proposal for that use case.

> Feedback from JDK 21 suggested that String Templates should be finalized for JDK 22.

Would be nice if they detailed the received feedback.

Reply on news.ycombinator.com