I'd also really have preferred $, but apparently there's some backwards compatibility issue with using that character?

“${val}” is a legal string literal that is certainly used in plenty of existing programs.

In current Java you would have to escape \, so only “\\{val}” could have existed before.

That's why JS use ` and not reuse ".

You want the lexer to be able to make the difference between a constant string and a template string and you want users to be able to read the code.

This JEP solves the former not the later.

It’s not as bad as people make it out to be. Swift without any backwards compatibility constraints chose “\(val)”. It does need a slight getting used to but it is not any worse than ${}.

Swift’s choice is strange and ugly IMO, even if it did not involve backwards compatibility constraints.

For another n=1 opinion, I like Swift’s choice, even though it’s different from convention. It’s lighter, typographically. ‘${‘ draws more attention to the delimiters than ‘\(‘.

And yes, the delimiters could be made less obtrusive using syntax coloring, but not all tools will do that (e.g. when using grep on a code base)

Swift’s choice has the advantage of visually unifying the two cases where text in a string literal is interpreted as something other than the text itself. One is backslash escapes like \n and \\. The other is string interpolation.

Isn’t the STR.” prefix enough to distinguish traditional strings from format strings?

` would be even more difficult to type, and is easily confused with '.

On European (other than British/Irish) keyboards where it exists, it will often be a dead key.

I'm not a fan either. Java seems to be declining in prevalence in my corner of industry, I'm sure these changes are made by wiser minds than mine, but I'm sceptical about whether such a choice is really right for users.

I remain to be convinced and program daily in Java for a long time.

It seems just as difficult to remember/useless as lambda expressions that look fine as vanity one-line expressions and then get difficult to write for most programmers.

We don't really need vanity innovation in the Java world. I would have asked for priority on the FX replacement to Swing, or support for running on ESP32 IoT devices as replacement to the Arduino platform.

Instead we get some weird looking syntax for what is basically a non-problem.

¯\_(ツ)_/¯

> We don't really need vanity innovation in the Java world. I would have asked for priority on the FX replacement to Swing, or support for running on ESP32 IoT devices as replacement to the Arduino platform.

Which are entirely unrelated projects to this one with very different engineers working on it. Those are easily parallelized, if you will. I don’t see why having progress completely elsewhere by different people is detrimental to these goals at all.

Because this thing here adds complexity to the language.

I'll be fine and ignore it completely like I've done with lambdas. I just pity the fools who enter Java world to learn the language and will suffer trying to learn what they believe is something normal programmers use.

Poor souls.

JavaScript basically has the same functionality but with ${}. Anyone who uses named parameters in HQL or SQL queries would be very grateful for this feature as it means you no longer have to type out the same name three times for each parameter.

Still don't get the need for it.

You could always use the + operator to join strings. Even a external library would do just fine when you want to insert some kind of variable name inside strings for that purpose.

Don't really get the need for this to be a core function with such a java-unlike grammar.

I assume because `\{` was not a valid escape sequence, which means any use of this character pair can be identified as a template without changing the semantics of existing string literals.

Bingo!

More specifically: https://news.ycombinator.com/item?id=35016204

This reminds me how PHP ended up with weird characters for various things (like namespace separators) because it was just easier to parse.

PHP never stood out as a language with very clean syntax. It is very PHPesque to put the burden on the user of the language instead of going the extra mile and implement something that might be harder to parse, but would be more consistent. Inonsistency in general is one of PHP's issues.

if you ever had the misfortune of seeing the code for the parser and lexer of earlier versions of PHP youd see that it wasnt due to parsing simplicity but rather the author making poor syntax decisions due to a lack of understanding.

Then being walled in by backwards compatibility

Interesting, but not surprising for a language where functions were "hashed" as their identifier's string length. Do you have a link?

I do not, it'll be in whatever version control php is in though I'm sure.

Another absolute horror parser was the wikipedia wikitext parser. An ambiguous hand written mess of epic disgust.

But you need the `FOO.` prefix anyways. So there was never any ambiguity. It seems that it would be good to either make the prefix optional (presumably something equivalent to the `STR.` processor would be default) or keep the interpolation syntax clean. (IMHO just `STR."Hello {name}!"` would have been ideal). But instead they require both the prefix and the ugly interpretation syntax.

Seriously, yes. Great thought process behind the design, marred by the good-for-nothing (subjective opinion) backslash.

If any of you design a language or a DSL, please, please - avoid the backslash - for the reasons stated above. Hard to type, introduces unseen problems, most will hate it. It (backslash) is unbecoming, of anything elegant.

But if you do follow that advice consider if it is worth just using a different escape character for all interpolations. That way could still make use of this very sensible syntax of reusing the escape for interpolation whilst avoiding the backslash issues.

I don't understand this rationale either:

> For the syntax of embedded expressions we considered using ${...}, but that would require a tag on string templates (either a prefix or a delimiter other than ") to avoid conflicts with legacy code.

Can't the template processor expression itself function as the tag? Is STR."..." already legal now?

They want

  String info = "My name is \{name}";

to be a compile-time error because it is missing the template processor (e.g. the `STR.` prefix). Since existing code like

  String info = "My name is ${name}";

is valid, they can’t use that syntax, or any other syntax that is currently allowed, since otherwise they would lose the ability to make it an error.

Futzing around with quotes like that is worse to type and it’s nice having distinct characters for open and close.

It makes perfect sense to have the expressions outside of the string literals, exactly because they are expressions and not literal. Quotes express literalness, the opposite of evaluation.

This is simply replacing the existing

  "My name is " + name + "."

by

  "My name is " (name) "."

by eliminating the plusses, and adding parentheses to make expressions like

  "My name is " ("John") "."

unambiguous (a string template with one parameter that happens to be a string literal). The parentheses also indicate that this is a parameter (to the string template) that is immediately evaluated, like for a function call. (The whole string template feature is really just syntactic sugar for a function call.)

That way you don’t have to “interrupt” string literals with an expression. Instead you end the string literal normally and then comes an expression.

A string template would be defined as any sequence of string literals and parenthesized expressions.

I get that, but it’s hard to type accurately.

I agree. On my keyboard I need to press ⌥ + ⌘ + 7

It's actually made worse because { and } also need special combinations.

To type \{X} I need to press

  (⌥ + ⌘ + 7) (SHIFT + ⌥ + 8) X (SHIFT + ⌥ + 9)

I know this is something we need to live with due to historical reasons, but I would prefer that new syntax is made simpler.

What about parenthesis () and square brackets [] ? (writing a lisp DSL that might have users from non-US layouts)

They are ok to use

I press ⌥ + 8 for square brackets and SHIFT + 8 for parentheses.

It's probably not possible to find better alternatives that could be used for a language based on Lisp syntax.

The keyboard simply doesn't have any dedicated keys that are not used for normal text. (Except @ on Mac keyboards, but Windows keyboards require a combination for that)

I think the umlaut key exists on Norwegian and Danish keyboard so occasional Swedish and German names can be typed.

Agreed, the economics for this syntax is terrible.

You just made me to get my MacBook out of closet :) (I stopped using it two months ago and moved to X1 carbon right before pandemic)

The ergonomic of \{X} is exactly the same on it as on my carbon x1, my keychron tls and four other keyboards I happen to have in my drawer.

Are You using modified Apple II like Rebecca Heineman or some kind of super small keyboard that looks like someone forgot to put all the keys in :) ?

Either way its on you not Java.

(Dont take this wrong way - this is an honest question - here in Poland almost all keyboard are backslash friendly and I would live to knowe where this is not the case)

It's a standard full sized Mac keyboard for Norway. We share the keyboard with Denmark too I think. The Swedes and Finns have different keyboards, but I think they use a similar combination for backslash.

So the Mac issue applies to 4 countries in the Nordics at least. Please note that traditional PC keyboards use a different layout for some characters and may in some cases have a dedicated key for backslash too.

Regarding backslashes and other special characters, I never said it's on Java specifically, but the US centric culture in general. K&R used curly brackets when they designed Cbecause they fit the US teletype character set of the 60s/70s, but that doesn't mean it's the best choice today.

Yeah, I agree that it would be nice to have option that works for all and takes all National quirks under consideration.

Do You have some specific way of template definition in mind that You think would work here?

And what about curly brackets, especially in context of templates, what would you use instead?

Slightly unrelated, but I only buy ISO keyboards and have my native tongue layout (Hungarian) and English easily switched. The former absolutely sucked for any programming work, so I think we just sort of have to accept that programming is done with an en-us layout, the same way that (hopefully) all identifiers/comments are also in English.

I don’t mind the typing ergonomy. More that it is visually ugly and counter-intuitive. Because in every other language a backslash would mean you want to keep the braces instead of interpolating the variable inside. They even have a comparison table at the top of the document, where they didn’t dare to put the Java option next to the others because it would stand out as being too different. Why not just follow the established conventions?

It’s the “escape” character.

It's horrible but I can't get over it. The value of string template is also aesthetic.. and these are like staples. Java once again.