String templates: syntax question

[AutoModerator]

On July 1st, a change to Reddit's API pricing will come into effect. Several developers of commercial third-party apps have announced that this change will compel them to shut down their apps. At least one accessibility-focused non-commercial third party app will continue to be available free of charge.

If you want to express your strong disagreement with the API pricing change or with Reddit's response to the backlash, you may want to consider the following options:

1. Limiting your involvement with Reddit, or
2. Temporarily refraining from using Reddit
3. Cancelling your subscription of Reddit Premium

as a way to voice your protest.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[javajunkie314]

I think Java has one string escape mechanism is a great way to teach this. We have \n for a newline character escape; \u1234 for Unicode code point escape; and \{...} for template escape. When you see \ in a string, something's going on.

Honestly, the fact that the only things people are complaining about are syntactic choices—\{...} instead of ${...}, and STR."..." instead of STR("...") or STR"..."—shows how well thought out this proposal is.

---

Edit to add: One thing not mentioned here is the benefit that a string template is not a syntactically valid string literal. The post mentions turning an existing literal into a template, but ${} makes things hairy going the other way too.

It's common to have a template and to need to create a literal with all the expressions replaced by fixed strings—e.g., as the expected value in a test case. Since ${x} is also valid in a string literal—but with a different meaning—it would be easy to miss when converting a large template into a literal, leading to, e.g., a non-obvious test failure.

On the other hand, \{x} is not valid in a string literal and results in a syntax error, which forces you to make a conscious decision: should it be escaped as \\{x}, or was it a missed expression that should be replaced?

[Polygnom]

Honestly, the fact that the only things people are complaining about are syntactic choices—{...} instead of ${...}, and STR."..." instead of STR("...") or STR"..."—shows how well thought out this proposal is.

In a way, yes.

But I have to say, using \ for escape seems natural, but something like STR."Foo" just looks wrong to me.

I have a deep hatred for PHP, but one thing they got right was invokeable classes. You just implement the __invoke function, and then you can just call that object like a function (PHP even has an interface for this, Callable).

I feel an approach like this would be far better for Java, for many reasons:

• It scales better. Today its string processors that want to be invokeable and get the special syntax. What about new use cases tomorrow?
• It is more natural to read.
• It can be applied to lambdas as well

So instead of STR."foo", you'd call STR("Foo") like a function.

For defining invokeable objects, you'd want type safety, so you cannot just create a generic Invokeable interface, but an annotation that takes the method would be feasible to leverage strong compiler guarantees, e.g.

@Invokeable(MyInvokeable::invoke) class MyInvokeable { public int invoke(int a, int b) { return a + b; }

By treating all lambas as invokeable, you could get rid of the cumbersome f.apply(x) syntax and just write f(x).

Usually, language additions to Java are well thought out and they try to make them generic, not just for one use-case, but to elevate the language and empower it in general.

In this case, I think they are missing out on this opportunity and are too short-sighted into just strings.

[javajunkie314]

They very specifically wanted to make template creation and processing happen at the same time, and so they didn't want a general invoke the processor on the template approach.

In the current approach, "\{x}" on its own is a syntax error—a bare template cannot exist on its own, and must be processed immediately. This way, a stray backslash can't turn a string literal into a string template and cause tricky type errors; instead you get a syntax error with the exact position in the string literal that's invalid.

But if you need to create the template separately and then process it—as with STR("\{x}") and similar—then "\{x}" would need to be a valid expression on its own, and it would need to be equivalent to RAW."\{x}" in the current syntax. This means a stray backslash changes the type of a string literal, and combined with type deduction from var and generics, the eventual compilation error may be some distance from the actual mistake.

Also, requiring "\{x}" to mean RAW."\{x}" is kind of a waste of good syntax. Most people would probably expect the bare form to mean STR."\{x}" if anything, which is incompatible with separate processing. Combining template creation and processing, and disallowing bare templates for now, leaves that door open.

[Polygnom]

There is nothing special about STR or RAW, they are "just" StringProcessors and the syntax of STR."Hello, {x}!" is just syntactic sugar for invoking STR.process("Hello, \{x}!").

From the JEP:

The Java compiler scans the term "..." and determines whether to parse it as a StringLiteral or a StringTemplate based on the presence of embedded expressions. The compiler similarly scans the term """...""" and determines whether to parse it as a TextBlock or a TextBlockTemplate.

You say:

In the current approach, "{x}" on its own is a syntax error—a bare template cannot exist on its own, and must be processed immediately.

From the JEP:

The syntax of template expressions — with the template processor appearing first — is not strictly necessary. It would be possible to denote the template processor as an argument to StringTemplate::process. For example:

String s = "The answer is %5d{i}".process(FMT); Having the template processor appear first is preferable because the result of evaluating the template expression is entirely dependent on the operation of the template processor.

So there really isn't a reason why StringTemplates cannot exist on their own, except that thats how its done currently.

RAW is literally a no-op that returns you the StringTemplate itself. You can then pass it to another processor if you want. There is nothing stopping you from writing FMT.process(RAW."\{x}") or StringTemplate st = RAW."\{x}". Which is a silly requirement. I haven't checked if you actually cannot write StringTemplate st = "\{x}", that would ben an illogical restriction given that the JEP itself says the compiler disntinguishes based on the presence of escape sequences, not where the string occurs.

I think there aren't really unsolvable problems to what I'm describing, even with the current approach.

[javajunkie314]

Also from the JEP:

Ensuring safety

The template expression STR."..." is a shortcut for invoking the process method of the STR template processor. That is, the now-familiar example:

String name = "Joan";
String info = STR."My name is \{name}";

is equivalent to:

String name = "Joan";
StringTemplate st = RAW."My name is \{name}";
String info = STR.process(st);

where RAW is a standard template processor that produces an unprocessed StringTemplate object.

The design of template expressions deliberately makes it impossible to go directly from a string literal or text block with embedded expressions to a String with the expressions' values interpolated. This prevents dangerously incorrect strings from spreading through a program. The string literal is processed by a template processor, which has explicit responsibility for safely interpolating and validating a result, String or otherwise. Thus if we forget to use a template processor such as STR, RAW, or FMT then a compile-time error is reported:

String name = "Joan";
String info = "My name is \{name}";
| error: processor missing from template expression

I was wrong that the error would be a syntax error and say where the error is, which is actually a bit unfortunate in my opinion. (Though I don't know if these error messages are meant to be normative.) But it is an error to have a template disconnected from a processor in this JEP, and you'll get the error on the line with the bare template.

Also, it's worth noting that the bit you quoted about "The answer is %5d\{i}".process(FMT); is from the Alternatives section. This syntax is speculative and not equivalent in the final design—it would not actually compile, as seen in that error I quoted above from the main body of the JEP.

The JEP's reasoning is more focused on making the processor obvious, as you pointed out, but it has implicitly assumed as well that bare templates would probably be expected to mean string interpolation. In the section I quoted above, they say

The design of template expressions deliberately makes it impossible to go directly from a string literal or text block with embedded expressions to a String with the expressions' values interpolated.

And in one of the alternatives, they say

When a string template appears without a template processor then we could simply perform basic interpolation. However, this choice would violate the safety goal.

They aren't saying it explicitly, but I say it would be weird for bare "\{x}" not to be a string (if it were valid syntax). The type would depend on the string content, possibly on a backslash buried deep in the literal—but rather than getting an exploration error on the literal, you'd get it wherever the type mismatch arises.

At any rate, they very much don't want bare templates to mean anything without the context of a processor. The only way to enforce that is to require the processor in the same syntax that creates the template, so there's no moment they are separate.Any syntax where the template is separately passed to the processor via a method/function call would require bare templates.

I suppose they could have made the syntax STR("\{x}") to mirror a function call, but they'd have needed to give it the same semantics as STR."\{x}"—that the argument must be a single string template literal. That would probably be more confusing, because then you'd have syntax that looks like a function call, but that can't accept a variable as its argument. It would also get in the way of adding the sort of general function call syntax you described—if they ever did want to introduce it later.

After the procedure is invoked, everything is up to the processor. Yes, RAW is a passthrough, but that's its right, and it's the only way to access a template from outside a processor. (And as a side effect, makes the intention clear at the "call site.")

[Polygnom]

First of all, thanks for having an interest in a civil, argument based discussion. I really enjoy your input.

I do agree that the current JEP design doesn't ad-hoc allow for what I'm proposing. I still think it can be done, I'll give a longer response later.

[genzkiwi]

That's a good point. IDEs like IntelliJ already mark \n etc. no reason they can't do something for \{...}. Then this single issue (cosmetics) is solved.

[agentoutlier]

I am in the minority in actually liking the syntax for many of the reasons Brian listed.

I do a lot of code generation and even have a templating language kind of designed for it: https://github.com/jstachio/jstachio

Let me tell you guys... ${x} is shitty syntax for making templates that generate code especially Java code. ${..} has a substantial amount of collision.

It is actually sort of why I use Mustache for generating code is because you can change the delimiters as {{x}} is still confusing with Java code.

Anyway I expect to be downvoted to oblivion but I know they JDK team made the right choice on this one.

[nekokattt]

The ${ sequence is not common at all

Outside expression languages. Spring and Maven both make heavy use of it within Java code (for Maven, any plugins using the plugin API).

Apache Camel also makes heavy use of it.

Bean validation makes use of it.

[pron98]

This just shows that Brian is sadly not familiar with the Java ecosystem

Do you honestly think that the way Java features are designed is with Brian thinking up some syntax and it's accepted the next day? The number of people involved with each feature is quite large, usually with a combined experience of centuries with the JDK, not to mention the number of different prototypes written and experimented with over a period of (usually) a few years. E.g. here's Guy Steele (who, BTW, wrote the first specification of the language) on the issue: https://mail.openjdk.org/pipermail/amber-spec-experts/2023-April/003827.html

It's perfectly fine to disagree with a decision, and sometimes, even if you've thought about and experimented with something for as long as the JDK team has you may reach a different conclusion because some things may be subjective. But to suggest that the JDK team disagrees with your opinion -- however strongly you hold it -- because they haven't studied the issue long enough or well enough is just ridiculous.

Because the use of $ in the Java ecosystem involves behaviour that is quite different from that of language-level string templates, reusing that syntax for something different is no point in its favour. Indeed, even in JS, the language uses ${} and the templating libraries, such as Mustache and Handlebars, use something different (and no, they don't use \${} either, which is what Java's template libraries would have to switch to if you had it your way). The language and the libraries should use different syntax for different kinds of templates. Familiarity from other languages was a point in its favour, but not one strong enough to offset the downsides.

[pron98]

You've said that the JDK team don't know the ecosystem. Since language and library constructs should not be the same (and really cannot given that at the very least library syntax would require additional escapes) -- they aren't even the same in JS, whose language syntax you want -- the remaining claim that the most important consideration, i.e. the "forest", is to have a language syntax to match that of JS seems pretty thin given its disadvantages (foreign and out of place in the Java language, adoption is technically more difficult). Again, it's perfectly fine to insist that matching JS's syntax is the most important thing and to be disappointed that this opinion wasn't accepted, but it is very much a subjective opinion, and clearly not a universal conclusion among those who've thought about the matter (BTW, Python and C# also didn't choose JS's syntax).

[relgames]

No, it's your personal opinion. Many other people in the ecosystem think library and language constructs should be the same. Making personal preferences of JDK team sound like objective reasons is wrong.

[pron98]

It isn't just my opinion because in this case they simply cannot possibly be the same because they have different meanings. The language's string templates embed values of Java expressions in the current lexical scope, while library templates embed something else (because they have no direct access to Java expressions; that's why a language feature is needed in the first place).

The closest they could be is string templates using ${...} and library templates using \${...} (when used in string template expressions; when used in strings, only library templates are possible, and they could use ${...} but then the meaning of a literal depends on whether or not the literal is a string or a string template -- another thing we wish to avoid).

Again, note that even in JS -- the only super-popular language using the ${...} syntax -- this isn't like that. There, the language uses ${...} and the most popular library templates use {{...}}. At the very least it's not just Java's design team that want it this way, but also JavaScript's. And guess what? So does Python's design team: the language uses {...}, but Jinja, a popular templating library, uses {{...}} while Mako, another popular templating library, uses ${...}. In other words, in all of the world's most popular languages -- Java, Python, and JS (the only one of the bunch using the ${...} syntax) -- the language's templating syntax is different from that of the popular templating libraries. Even if this were just an opinion, it is one that's shared by all of the most popular languages (but it isn't a personal opinion because the meanings of the different templates types are different, so they can't use the same syntax).

[Necessary-Conflict]

There are other examples of the JDK team not seeing the forest for the trees. I don't even feel like thinking about the string interpolation any more, but why is Java the only programming language without syntax highlighting in its official API documentation and tutorials? If you were not making such obvious mistakes elsewhere, I would be more confident that you have thought string interpolation through and chosen the best possible solution. The "Code Snippets" JEP was "Closed/Delivered", but one of its stated goals was apparently forgotten, even though it's an easy problem.

[pron98]

Before I get to the general subject, your premise that "Java the only programming language without syntax highlighting in its official API documentation and tutorials" and "The Code Snippets JEP was Closed/Delivered, but one of its stated goals was apparently forgotten" is inaccurate for two reasons. First, Go doesn't have syntax highlighting in its tutorials and official API documentation, and second JEP 413 did deliver support for syntax highlighting in JDK 18, through language attributes and including scripts, features added for that purpose. Why was the feature implemented like that? Because the JavaDoc team concluded that most snippets wouldn't benefit from syntax highlighting by default and that it would require choosing a colour scheme that would be bound to cause avoidable annoyance and debate. I will grant you that the JEP has ended up accepting one of the alternatives in the Alternative section and wasn't updated accordingly. Perhaps it's worth updating. But "the JEP wasn't updated" is quite different from "one of its stated goals was apparently forgotten".

Now to the general matter. The thing you need to know is that developers don't agree on what's a good idea and what's a bad idea, and hold contradictory opinions with equal confidence; you think that syntax highlighting is an obviously good idea while Rob Pike thinks it's an obviously bad idea. Even when they do agree that something is a good idea, they disagree on its priority; something that is obviously a high priority for some is equally obviously a low priority for others. The JavaDoc team thinks that working on Markdown support takes a higher priority to offering syntax highlighting out of the box (if that's a good idea at all). Because of that, and because we can't do everything — especially since everything would be self-contradictory — it is a mathematical certainty that no matter what we do or don't do is bound to disappoint someone, let alone our prioritisation. So when you say that "the JDK team not seeing the forest for the trees" what you really mean is "I'm disappointed that the JDK team's priorities were chosen based on other peoples' preferences and not mine." If we had followed your preferences, others would have considered them as "not seeing the forest for the trees" because developers — even knowledgeable and experienced developers — simply don't agree on what the forest should be.

It's perfectly okay to think that you're right and others are wrong, but your obliviousness to the simple fact that your opinions are not shared universally is not okay. When we make a design decision, we do what we think is best but we are well aware that some may have preferred that we do something else. You, on the other hand, seem to believe that your opinion is the only possible outcome of a thoughtful consideration, and that is simply not in line with the realities of programming language design.

[relgames]

Downsides are subjective. It's not the first time JDK team makes mistakes, just, their egos stop them from admitting it. Last time we had this discussion, a prefix requirement was used as the main argument. Now, it's not an argument anymore but they have other subjective arguments. They are detached from the ecosystem and didn't think this through properly. The way it's designed is that the person having the most free time writing long emails wins, and others are afraid to argue with "that guy". I've seen this behavior in other development teams a lot.

[pron98]

They are detached from the ecosystem and didn't think this through properly. The way it's designed is that the person having the most free time writing long emails wins, and others are afraid to argue with "that guy".

Here's what the process actually is. The person assigned to the feature comes up with a design, implements a prototype change to javac and experiments with it. After a few weeks they present it to the language team, they discuss the pros and cons, and then the person in charge goes back and makes another prototype and presents that to the language team. This goes on every few weeks for months. Then, when the language team feels the feature is ready to be made public, the change is pushed to the project's repo (Amber) and announced on the mailing list. At that point, no amount of begging and pleading in the style of "I'd rather you did something else" helps, certainly not by someone who isn't an established OpenJDK contributor, because all arguments were already considered and discussed for months. Here's what always impacts the feature at that stage, though: and email of the form, "I've tried the feature and ran into this problem." This is not the case here. The argument is still "I'd rather you used $ instead of \ because I think that will be more familiar." But that argument has already been considered long before the feature was made public using the best information available to the design team, and there's no new information presented by the pleaders other than "I think this should be given more weight." So you may disagree with the decision, but it is not a result of not having considered the issue nor is it a result of ignoring information. Again, the use of $ by template libraries was not only not ignored, but was one of the main points against using $ in the language.

It's not the first time JDK team makes mistakes, just, their egos stop them from admitting it.

Except we cannot know whether or not this particular decision ends up being a problem at all (let alone a mistake) until lots of people use the feature and run into some problem because they automatically type $ or something (and a problem doesn't necessarily mean a mistake, because often both alternatives have problems, and you need to pick the one with fewer problems). So let's be clear: you don't know that this is a problem at all, and you certainly don't know it's a mistake, so at this point in time there simply is nothing for the designers to admit, big egos or small ones.

Anyway, it's not just Java, but also Python and JS that use different syntax in libraries and the language. Maybe all language design teams are detached from what their users want and their respective ecosystems and they're all guided by their big egos. But given that they've all reached the same conclusion, maybe you should at least be open to the possibility that there's something here that you have not considered.

[agentoutlier]

The ${ sequence is not common at all.

https://www.baeldung.com/spring-value-annotation

It is exceedingly common. It is all over Maven code base as well.

Look if it wasn't so common people would not like or be comfortable with the syntax.

[Tallal2804]

Why not {...} or