One of the ugliest implementations I've seen
I'm happy Java enhancements don't settle for half-baked features, and carefully avoid backwards compatibility issues. Yes the syntax is verbose like that of many recent features (like sealed classes) but honestly given modern tooling, who cares?
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.
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.
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."....";
> 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.
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.
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?
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.
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.
Absolutely nothing precluded extending the new syntax to swallowing / obviating the `.`.
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.
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.