Hacker News Reader

Comment by mhosain | Hacker News Reader

Sadly, true. Why is the template processor named `STR`, why not `f"String"`, like Python? On top of the ugly `STR.` prefix, this dreaded `\` character infuriates me more. Kotlin and Groovy have the nicest implementation by far because it doesn't require any prefixes. I understand Java can't suddenly do that because it needs to be backward-compatible.

I can't get over the ugly `\{someVar}`. It will be easily confused as the `{` character is being escaped, rather than a template. `${someVar}` was a much better option.

View on HN

> Sadly, true. Why is the template processor named `STR`, why not `f"String"`, like Python?

It looks like the prefix is pluggable so you can use different template processors, STR is just the default:

> STR is a template processor defined in the Java Platform. It performs string interpolation by replacing each embedded expression in the template with the (stringified) value of that expression.

> FMT is another template processor defined in the Java Platform. FMT is like STR in that it performs interpolation, but it also interprets format specifiers which appear to the left of embedded expressions.

> Developers can easily create template processors for use in template expressions.

This is similar to Javascript's `tagged templates`: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe.... Python's f-strings are very much lacking that.

Although I do agree that the syntax, both of the prefix and the interpolation symbol, is awful.

> the ugly `STR.` prefix

STR is not a prefix but simply the name of the variable referencing the receiver (template processor) of the call, i.e. you can do:

    var x = STR;
    x."....";

In Java, making instance method calls requires a receiver to the left of a `.`. Even though template processing has special syntax, it is still a call to an instance method defined by a normal Java interface, and so, as always, requires a receiver. The new syntax here is what's to the right of the `.`; what's to the left is old syntax.

> It will be easily confused as the `{` character is being escaped

It is being escaped, and so reading it as being escaped is the correct and intended understanding. Just like `\n` or `\t`, `\{` means that the next character has a special meaning, as it always does in Java. There was no need to introduce yet another escape sequence; the old one works just fine.

> STR is not a prefix but simply the name of the variable referencing the receiver

That is THE problem. You can use StringBuilder more easily than this ugly thing. When you write code in IDE (I hope so), writing `.append()` is actually easier than this `\{}` dreadful thing.

> It is being escaped, and so reading it as being escaped is the correct and intended understanding. Just like `\n` or `\t`, `\{` means that the next character has a special meaning, as it always does in Java. There was no need to introduce yet another escape sequence; the old one works just fine.

But what about the `}` after the expression? Who/what is escaping that? It should make it clear that this is a special syntax that does some special things. `\` is sort of universal escape character. Putting it in here feels wrong. Again, that's me (along with some other), and you definitely can disagree.

> You can use StringBuilder more easily than this ugly thing. When you write code in IDE (I hope so), writing `.append()` is actually easier than this `\{}` dreadful thing.

How long have you been using string templates? If you've had a bad experience, please report it to the amber-dev list. If it's speculation, I suggest you actually try the feature for a while.

Also, I think you may have misunderstood what this feature actually does (please read the JEP). StringBuilder produces strings, but string templates are most powerful when you're not producing strings (and `append` does enforce sanitisation/escaping). This feature is not string interpolation (although it could also be used for string interpolation as a special case), and its function is completely different from that of StringBuilder. StringBuilder simply cannot do what this feature does regardless of your thoughts about the syntax, which may or may not be formed after actual experience.

> But what about the `}` after the expression? Who/what is escaping that?

You don't need to. `\` in Java means that the next character triggers some special interpretation, and `\{` means that the interpretation mode continues until the `}`. The closing curly bracket should require no more of a special treatment than the characters inside the curly brackets.

> Putting it in here feels wrong.

When you say "feels wrong" do you mean you've tried the feature for a while and ran into problems or that you simply fear that you might?

> Also, I think you may have misunderstood what this feature...

No, I am aware of the differences between StringBuilder and string templating. One of the most common usage is concatenation (e.g. toString() methods). Sometimes it's cleaner to use StringBuilder instead of + operator to do that. And templating will be mostly used for concatenation.

All I am saying is, it could be simpler. I read the full JEP before my first comment. I frequently do Python and did little bit of Kotlin before. I guess that's where all this is coming from.

> And templating will be mostly used for concatenation.

Whether it will or won't, interpolation is not the reason for the feature, so clearly that's not the use case that should be prioritised, especially as it's been recognised as an exceptionally dangerous use-case. The starting point that we must in no way make string interpolation, which is known to be dangerous, any easier than using safer template processors.

This feature was created (among some other reasons) to solve the severe security problems created by string manipulation, not to make string concatenation -- which is already pretty easy -- easier. As the JEP explains, after a lot of thought the decision was not to offer string interpolation as a language feature and go for string templates instead. Saying that the feature doesn't accomplish well the thing it explicitly doesn't try to accomplish is really not saying much about the potential of this feature. Making string interpolation as easy as it could possibly be was not only not a goal of this feature, but the very thing it was designed to avoid given how dangerous that is.

On the other hand, consider that you can now safely embed HTML templates in Java code.

> I frequently do Python and did little bit of Kotlin before. I guess that's where all this is coming from.

In this case, as in many others, we studied what many other languages did, incorporated what's been learnt about code injection vulnerabilities, and did what we believe to be a marked improvement over other languages' features, at least as appropriate for Java's users. You may disagree, but a lot of thought has gone into the design by some of the world's most accomplished language designers as well as user testing, and so I don't think speculation trumps that. If further experience shows that we got it wrong, it can be fixed.

> The new syntax here is what's to the right of the `.`; what's to the left is old syntax.

Absolutely nothing precluded extending the new syntax to swallowing / obviating the `.`.

True, but nothing necessitated it, either. New features are tested by users for a while (and this one has even been a preview feature in a released JDK for some time), and the people who have actually used the feature didn't report that typing `.` was a problem to them. If further experience shows otherwise, then we could allow dropping the dot.

In other words, security vulnerabilities due to string manipulation are a real and pretty serious problem that this feature aims to solve (or, at least alleviate). If the dot character also proves to be a real problem, which it hasn't yet, then that could be solved later.

So weird that of all the choices they decide to use something used as an escape character.

The backslash is unsightly, I agree. Codifying template expression evaluators as a core part of the language, however, is a rational choice. Java is surprisingly foresightful in this regard - it means idioms in the language itself can guide people to getting the common use case of interpolating stuff correct. "STR" for the most prevalent case is perhaps a bit verbose, but at least it's explicit.

Yea, I’m actually a big fan of Java but my immediate reaction to the syntax here was wtf.

There's literally section called `The STR template processor`.

Yeah, but than what was the point? We could've continue to use existing methods.

The goal was getting something clean and friendly. Look at Python for example. Any similar solution would have made it both non-breaking (codes won't compile with unsupported version) and clean.

Reply on news.ycombinator.com