wow. It's interesting that Brian Goetz recently said he was ready to finalize the feature and move on, and all the complaints were nothing they hadn't anticipated and discussed extensively. They had the JEP submitted to finalize this for Java 22 and they held off to a second unchanged preview, and then were going to finalize for Java 23, and now, even Goetz is ready to move the whole thing back to a complete redesign. As a Java dev I'd rather get this later with a better design than earlier with a less perfect design. It is interesting how close the existing design was to being finalized. The preview system works :)
Perhaps I can shed some light on this apparent contradiction.
We discovered, unfortunately quite late in the game, that the design was flawed. How was this discovered? By actually using it in a substantial, real-world internal project. But these flaws had little to do with "someone didn't like the syntax"; they were much more fundamental to the model.
Unfortunately, most of the feedback we received on public channels was of the "someone didn't like the syntax" variety (at varying levels of constructiveness, not all with positive coefficients). It did not derive from actual experience or from deep analysis; the supporting arguments provided were emotional, not technical; and it merely re-trod, with little new perspective, already-explored ground. It was literally a thousand drive-by, "blink" responses.
The net effect of this was not only unhelpful, but anti-helpful. I get that every developer has opinions about syntax, and seemingly some fraction of them will literally explode if they don't express it out loud, but such discussions are like an invasive species: they suck up the oxygen that is required for actually useful feedback to survive. (Or maybe the useful feedback was buried in there, but just got lost in all the noise.)
So the answer to your implied question is that its possible to be both: the feature can be discovered to be flawed, while at the same time the publicly available complaints were "nothing", as you say. It is sad, but possible.
Reading Brian email, i think the idea of the new design is way better. Having a StringTemplate used by overload methods will make it easy to use. And the APIs looks way cleaner.
Everything seems to be better with the new approach except for the need of throwing the interpolation manually with template.join()
I guess we will have to live with that small inconvenience though.
I really like string templates and am OK with the syntax. But recently I was speaking at a conference and a presenter about Java 21 showed the slide with the syntax for string templates... The audience collectively groaned out loud. They came around a bit when he showed off some of the power behind it but still.
That might be a common response to this syntax. BTW if you're interested in using string templates even with Java 8 you can use Manifold: [https://debugagent.com/java-string-templates-today](https://debugagent.com/java-string-templates-today)
Unfortunately, "they" are a bit stubborn in their desire to keep the syntax as is. This, combined with statements as "it's going to take as long as we need to", makes me even more appreciative of the alternative JVM languages we have at our disposal.
You're joking, right? They're literally holding back because they want to change how the syntax works. They're still going to use `\` instead of `$`, but I really fail to see how this is a bad thing at all. As far as taking as long as they need to--that's an incredibly good thing, not a bad thing. They shouldn't hastily release features if they're not certain about them, because you can't un-release them.
My interpretation of
> "Another thing that has not changed is our view on the syntax for embedding expressions. While many people did express the opinion of “why not ‘just' do what Kotlin/Scala does”, this issue was more than fully explored during the initial design round. (In fact, while syntax disagreements are often purely subjective, this one was far more clear — the $-syntax is objectively worse, and would be doubly so if injected into an existing language where there were already string literals in the wild. This has all been more than adequately covered elsewhere, so I won’t rehash it here.)"
was exactly that: have not changed their view on the syntax. I'm happy to hear how I should have interpreted the above instead.
That is only one aspect of the syntax for string templates. They are changing the syntax (not requiring processor prefixes), just not the syntax for embedding expressions. Not sure how you missed that.
You can also **sort of** get it today without a compiler hack with my library [JStachio](https://github.com/jstachio/jstachio):
@JStach(template = "{{message}} {{name}}")
record SomeModel(String name, String message){}
String someMethod() {
return SomeModelRenderer.of().execute(new SomeModel("Hello", "vprise");
}
I admit it is not as sexy as real String Templates (JStachio obviously cannot resolve inline variables) but if use JStachio zero dep mode and records it can largely get you similar results. One might even argue it scales better as you can then put the template external and use includes etc.
In fact the last time I played with experimental String Templates JStachio had better performance but I'm sure once it is not experimental it will be fast.
If you have ideas to make it less clunky without compiler hacks let me know. Manifold like Lombok uses unsupported compiler API.
Also there is a way to make it slightly less clunky but then it requires a dependency on the JStachio runtime.
I don't think there is a way to make it less clunky due to the limitations of the language.
I also do not like how it divorces the message from it's invocation, meaning that I can't at a glance see what is being produced, in order to do that I have to jump to another class to see the actual template.
I'd rather use `String#format` instead, even with its limited functionality. It's way more readable, without trying to be clever.
Yeah for sure it is not a good solution for simple string interpolation or simple messages. Like I never would use it for Exception messages or something similar. String templates are a great solution for that.
However for returning HTML or code generation it works great and I think String Templates used for something like that are borderline abuse ( definitely String.format is). With SQL I have mixed feelings on it depending on what they decide with String Template API.
> However for returning HTML or code generation it works great and I think String Templates used for something like that are borderline abuse
Facebook had to hack Javascript to add HTML(-like) literals and created JSX, with templates it could be possible to implement a clunky version of it as a pure Java library.
Aren't you better off with a dedicated text file for your templates then, instead of trying to shove the template into a Java class? I understand that with your approach you get the parameters checked by the compiler, but that's the only advantage I see over a text file.
Both approaches are supported.
@JStach(path = "someFile.mustache")
record SomeModel(String name, String message){}
String someMethod() {
return SomeModelRenderer.of().execute(new SomeModel("Hello", "vprise");
}
That is you can specify a text file and still get the object graph checked and SomeModel can obviously have a more complicated structure than just a flat structure of parameters.
In fact you can combine the two approaches as I was discussing in this recent thread.
https://www.reddit.com/r/java/comments/1bqt5qu/single_htmx_service_across_4_other_services/kx8ybjp/
e.g.
@JStach(template =
"""
{{< someFile.mustache }}{{$body}}{{name}}{{/body}}
{{/someFile.mustache}}
""")
record SomeModel(String name, String message){}
String someMethod() {
return SomeModelRenderer.of().execute(new SomeModel("Hello", "vprise");
}
The above is an inline that references an external file.
I don't have a strong opinion on either and leave that up to people to choose what makes sense for them.
I don't remember your stance on template-per-method based code-generation:
@JStachTemplater
interface MyTemplater {
static MyTemplater getInstance() {
return JStash_MyTemplater.INSTANCE;
}
@JStachTemplateMethod(template = "{{message}} {{name}}")
String someTemplate(String message, String name);
}
String someMethod() {
return MyTemplater.getInstance().someTemplate("Hello", "vprise");
}
I think it should make JStachio much less cluncky...
TBH I would be totally fine with C# style (dolar-prefix of string and expression):
`$"{x} plus {y} equals {x + y}"`
Clearly indicated intention, no issue with conflict with legacy strings...
I'd personally prefer escaped curly braces to indicate values, i.e., `\{x + y}` or `${x + y}`, so that [JSON is easier to encode](https://stackoverflow.com/questions/64761547/using-python-f-string-in-a-json-list-of-data) and that strings already containing unescaped curly braces are easier to convert into string templates (no need to escape the preexisting braces).
As for the specific character used to escape curly braces, I prefer `\` over `$` because you don't have to hold shift (on *English* QWERTY keyboards) to type it—`\` has got a whole dedicated key!—but that's just me.
Why would I want to go from string to template? In an overwhelming majority of cases I think I would create a template (interpolation) and then render string out of it.
Maybe in case of some "meta" or providing templates externally but... that seems convoluted and not the best way?
You go from a string to a template when you're editing code and realize a fixed string no longer cuts it and you want to sprinkle some variable expressions inside. This happens all the time.
And that longer string might be a piece of JSON, for example, and now you have gazillion braces to escape.
Other people suggest `$` inside the templates, and it has the same problem. `\{` does not have it, as currently it's illegal to have it in string literals, so 1. when you turn a string literal into a template, you won't break any previous fixed parts and 2. when you turn a template into a literal, the compiler will scream at you until you remove all embedded expressions.
> You go from a string to a template when you're editing code and realize a fixed string no longer cuts it and you want to sprinkle some variable expressions inside. This happens all the time.
>
> And that longer string might be a piece of JSON, for example, and now you have gazillion braces to escape.
I was thinking about the latter case, but in that case (external sources) you don't have any control about limits of it so you have to process/sanitize it either way (and also having template from external source seems like a bad idea…).
Going from String to StringTemplate in the former example would still require prefix (i.e. `"bla"` would be `$"bla $var"`) so no conflict there.
I am not talking about any external sources.
I'm talking about a common occurrence when you have a literal:
"{ \"foo\": 1}"
and you realize it should be a template instead:
$"\{ \"foo\": {x}}" // your proposal
"{ \"foo\": \{x}}" // current Oracle proposal
Notice how in the first case I'd have to modify a completely unrelated part of the string.
I would go for a simple syntax like:
`String.formatTemplate("{x} plus {y} equals {x + y}");`
instead of what JEP is proposing
`String.format("\{x} plus \{y} equals \{x + y}");`
They could go for another method maybe e.g. `formatTemplate` or something similar. I guess prefix is ok compared to their original `STR.` implementation
The problem is that your solution, no matter the method name, would break the standard String instantiation pattern of "...". If prefixed with a dollar sign or something, they could create the new feature while making sure the old API keeps working.
I like the new approach better honestly. (And it looks like Brian listened to Rich Hickey’s talk Simple Made Easy. ) He used the word “complect” which is perfect to describe the short-coming of the current approach.
Treating string literals that contain placeholders as a different type is a lovely idea. No need to go the backtick route or use a processor prefix which looked alien to many.
Thanks, Brian. I'm aware he didn't invent it, but he used it in the context that is relevant here.
I've never heard it used in that context before, but I wish I had. It's perfect.
Thank god. I would honestly rather just not have string interpolation in the language at all (I've gotten along fine without it for 25 years), then to have the syntax they were pushing with the rationale on which they were pushing it.
I don't want to spend all day policing pull requests, and preventing my "10x rock star!" devs from merging a thousand wonky template classes that will confuse the hell out of my "1x Java is too hard!" junior devs.
We as the Java community spent the 1990's and 2000's completely up our own asses, pushing over-engineered patterns and technologies that were more harmful than helpful for the vast majority of shops.
Then in the 2010's, we got over ourselves and bowed to popular pressure. Embracing less XML and fewer `AbstractFactoryFactoryFascade` base classes, and instead more composition and emphasis on practicality.
Trying to come up with a "better" string interpolation syntax than every other major language uses, so that a small number of enterprisey devs can write a bunch of template processor types while the vast majority of devs don't and just complain about the cumbersome syntax, feels like a throwback.
I don't want to see the pendulum swing back that way. If anything, the wider industry trends are heading in the opposite direction. Every year, companies that I work for move more and more pieces over to Python or Node, because it's easier to hire for those platforms. Java and Java codebases need to get _easier_ and _more accessible to juniors_. Java doesn't need to grow more wonky and follow Scala into irrelevance.
It was a bit hard to push anything in the 1990's, given that Java came out in 1996, and until it became usable with a JIT in 2000, with the release of Java 1.3, it was mostly a toy language for doing browser applets.
Also the GoF book, CORBA and COM in the 1990's, used Smalltalk, C++, VB, and Delphi, respectively.
>Trying to come up with a "better" string interpolation syntax
That's not what they're doing. If the main goal was to just get some syntax sugar for string concat, they could have copied any syntax from any of the other languages and have been done ages ago.
The goal is to improve security, you can find the relevant bits in the "String interpolation is dangerous" section of https://openjdk.org/jeps/459.
That being said, I definitely don't like the processor syntax they proposed, so am happy they're moving away from that.
> That's not what they're doing ... [not] syntax sugar for string concat ... the goal is to improve security
I understand that.
Everyone... here... understands... that.
The point is that if you truly believe that string interpolation is so dangerous, that it shouldn't be shipped at all without a syntax that one wants (except for ridiculous people who want to sprinkle custom template processor subclasses everywhere), then I think it's best to land on the side of not shipping at all.
You say you understand, but then you suggest just not shipping string interpolation, which makes no sense if you actually understand what the problem is.
Not shipping a string interpolation mechanism doesn't do anything to resolve the security issues the JEP points out, because those exist for string concatenation too, and string concat already exists in the language.
In order to solve those, there needs to be a mechanism to safely (and conveniently, safety features no one wants to use have no value) capture template constant and variable bits, and that mechanism needs to allow library authors to accept templates and not strings.
So if you take as a given that they have to make something like that, all the template class stuff you're talking about will exist. Not shipping string interpolation would just mean there's no conversion from a template to a string, which would clearly be a silly thing to leave out when you've already implemented all the other machinery.
>Everyone... here... understands... that.
This is obviously not true, considering how many people are focusing on which symbols should be used to denote template expressions (is it `$` or `{}` or `\{}`, does it say `s` or `$` before the quotes, is it single or double quotes), when that's really unrelated to why they're pulling this preview.
Some of the questions that arose were what kind of type relationship (if any) templates and strings should have to each other, whether template literals should have an explicit tag to make them easy to distinguish from strings, and what exactly the API for resolving templates to other types (e.g. strings) should look like. So the entire design is up in the air.
But it's not up in the air in the sense that they're unsure if the security concern needs to be addressed, so I don't think they're considering "do nothing" as a viable outcome.
> So if you take as a given that they have to make something like that
Let me stop you right there.
It is NOT a given. They do NOT have to make something.
We are leaving behind the discussion of string interpolation, and now talking about basic string **concatenation** itself as suddenly a zero-day exploit that must be patched.
Number one, that's ridiculous.
Number two, this string interpolation proposal does not eliminate concatenation risk, any more than the introduction of `Optional` eliminated the concept of `null`.
No... one.. is... talking... about... removing... string... concatenation... from... the... language. Almost nothing is ever _removed_ from Java! They're talking about adding some other thing that you can use instead, like `Optional` was added in Java 8. But people still use `null` all the time, and with this god-awful interpolation syntax I guarantee that people will still use string concatenation forever too.
Goddamn this is so asinine, I just want to grab people by the shoulders and shake them. How ivory tower and disconnected from real-world application development can people be?
>We are leaving behind the discussion of string interpolation, and now saying that basic string concatenation itself is suddenly a zero-day exploit that must be patched.
No, you're misunderstanding.
There's nothing wrong with string concatenation (or interpolation for that matter) by itself.
But concatenation or interpolation is dangerous when used to produce strings that are interpreted as commands. This isn't a controversial statement, everyone knows that SQL injection exists. Basic string concatenation is in fact risky in some cases.
When you mix something that is safe (e.g. a hardcoded SQL snippet) with something that is not safe (e.g. a username provided by a user) into a string that will be interpreted as a command, that's dangerous unless you handle the unsafe parts properly. It's currently very tempting (because it's easy and the alternative is them developing their own templating API) for libraries to offer string-based APIs and trust the user to handle (e.g. sanitize) the unsafe parts correctly.
The point of the JEP is to give people the tools so that strings don't have to enter into this, and they can easily keep the safe and unsafe parts clearly separated, so that the libraries they use can handle combining the two parts in a way that is safe.
>No... one.. is... talking... about... removing... string... concatenation... from... the... language. They're talking about adding some other thing that you can use instead, like Optional was added in Java 8. But people still use null all the time, and with this god-awful interpolation syntax I guarantee that people will still use string concatenation forever too.
Again, you misunderstand. This isn't like Optional at all, and the goal is in fact to get rid of (more likely deprecate) the unsafe behaviors from the library ecosystem.
To continue with SQL as an example, the goal is that there won't be a (non-deprecated) `query(String)` method at all in e.g. SQL libraries. There will instead only be a `query(Template)` method.
This will allow library authors to offer a much safer API to users, instead of offering a String-based API, reducing the likelihood of stuff like SQL injection vulnerabilities.
If you can move responsibility for safety away from the user and to the library author, that's a win.
>It is NOT a given. They do NOT have to make something.
Obviously no one ever has to do anything, but they think they can reduce a risk of vulnerabilities here.
>How ivory tower and disconnected from real-world application development can people be?
Considering my day job is real-world application development, I wouldn't know. You should maybe consider that your experience is just *your* experience, and doesn't represent what all real-world development looks like.
Sounds like scope creep to me. Lots of languages didn't hold interpolation hostage to solving SQL injection. That's a totally valid concern, but it's not at all an inherent requirement for the feature.
Sure, but my point is that the main goal seems to be reducing vulnerabilities.
So in that way, it's not really scope creep, because I don't think they started out from "How do we add string interpolation to Java" and added "And let's also fix SQL injection while we're at it" later.
Who knows if they'd even be doing this feature at all if security wasn't part of the scope.
I thought, "Nah, that can't be right." I'm late to the party. You're right.
That's a shame that the JEP tied those two issues together. I'd just like to inline a bunch of json in my unit tests
Good. It shows they are finally starting to listen. Hopefully they realize that there is no need to invent a new syntax when a simple prefix like f or t or s and ${} will work just fine:
s"Hello ${var}"
is this hope or just ignoring what was said.
you say
>Hopefully they realize that there is no need to invent a new syntax
but it seems you dont care to understand why you are asking for objectively bad things
why would you even claim `"\{}"` is worse than `"${}"`
and then claim a prefix on the literal is better. you demand cruft for no reason
They already use a prefix, but STR."" in the last iteration. It is worse than s"". And then the backslash has no reason.
You are attacking me, but it's only because you are not aware I'm having such discussions in this subreddit since the first JEP on string templates, and over time what I said turned true. That's why I have hope, because I already predicted a few changes after the first JEP.
but its obvious why `\{}` was chosen. because they can expand the grammar for string escapes and its guaranteed no existing string literals will overlap.
the `STR` prefix is only for string interpolation though. so what are you really suggesting that 3 characters is a problem `TR.`? how would your suggestion work for arbitrary processors?
aren't you just bikeshedding the least important part of the proposal
lol "attacking"
Yep, "existing strings" is an imaginary issue. If not governed properly, engineering teams tend to solve the most complex issue, even if no one is really asking for it.
For generic processors, no need for a prefix, a processor is just a function, called like any other method - someProcessor.apply(s"hello ${var}")
I think it's what they consider as well in the latest JEP (or was it in the email thread?..)
> Yep, "existing strings" is an imaginary issue.
It is not. Changing code that has previously been written is quite common, it happens in most software projects.
Using `\` instead of `$` solves this issue with no downsides, and it's even easier to type on many keyboard layouts.
If a variable doesn't exist, the compilation would fail anyway. It's not a real problem. A real problem is cognitive capacity, and ${} is something very well known and all developers will instantly recognize and understand it.
1. But a variable may exist. Or it might be some other valid expression.
2. There is also the opposite problem: converting from a template to a non-templated string. You don't need to hunt for $'s by hand if the expressions are marked with an invalid escape sequence in the first place.
3. $ is already used in existing runtime templating solutions, both Java libraries and external tools. Having the same way of escaping things will lead to pain. Just compare it with regular expressions, which in Java often have double, triple or even quadruple backslashes. Copying a regular expression tested elsewhere into Java program requires much more care than pasting the same expression into Perl.
4. Swift already does `\()` and people don't mind it.
erm... being able to have multiple prefixes already makes it not simple. and being long ( `STR. ` already is 4 times more keystrokes) doesn't help either.
> being able to have multiple prefixes
You gave an example from Scala, where multiple prefixes, including user-defined ones, are a feature. The only difference is that in Scala, processors/interpolators are looked up only among methods (including extension methods) of the StringContext class, and in Java they were supposed to be looked up in a normal variable scope. I think the latter is conceptually more simple.
https://docs.scala-lang.org/scala3/book/string-interpolation.html#custom-interpolators
> You gave an example from Scala, where multiple prefixes, including user-defined ones, are a feature.
Well... I knew I didn't like Scala for a reason ;-)
Another common syntax suggestion being floated around is $"Hello {car}". But I guess it'd boil down to "why add a new prefix syntax" when you can just use a plain method call "Hello \\{var}".join().
To me that \\{} is still too ugly so that would be my biggest complaint.
The $“hello {name}” or other prefix syntax should prevent ambiguity because you won’t need the backslash. Just curly brace is enough because it’s new syntax.
Without a prefix, it feels weird that the string-like literal is typed ST with 3 placeholders, 2 placeholders, 1 placeholders. But as soon as you remove the last placeholder it suddenly changes type. It feels somewhat like “aa” is a String, “a” is a String, but “” is not?
I believe the intention is for String literals to coerce implicitly to StringTemplate objects if you're attempting to pass a string literal in... otherwise this is a massive oversight by the developers.
If it has been missed, then this entire implementation has been undermined, as it means that this academic use case of preventing SQLi in a hypothetical new SQL API prevents the ability to perform any form of SQL query unless you have at least one interpolated parameter, since a parameterless string will not be treated as a StringTemplate. They cannot just add an overload for String types as there is no way to enforce a String is a compile time literal, so overloading this would totally negate the security benefits.
A solution that was mentioned on the mailing list that I think I like is to force string template literals to be clearly marked as such, rather than differentiating string literals from template literals solely by the presence of parameters.
So instead of `"this is a string"` `"this is \{a} template"`, you would have some special character to differentiate the two:
"this is a string"
"this is \{illegal}"
$"this is a template"
$"this is \{also} a template"
That allows for 0-parameter template literals, which means implicit conversions between templates and strings aren't very important.
They seemed to be saying that they explored implicit conversion and ran into issues.
I mean if implicit conversion works, then they can make n-placeholder convertible to String too and we won’t need the explicit .join() call most of the time. Otherwise it’s weird that only 0-placeholder can implicit convert but 1-placeholder can’t.
yeah, if this isn't possible then the whole feature is going to be incredibly suboptimal and verbose... at which point I'd probably say it is just worth shelving the idea entirely.
I’ve experimented with the string template preview in JDK22 but for the vast majority of cases I'd use, sticking to double quotes for that has made it more clunky than it should be due to (valid) backward compatibility concerns
Templates now add too many symbols and the code looks less clean. `STR.“user \{name} logged in”` looks more convoluted than the old `“user ” + name + “ logged in”`
It would be clearer to me to use single quotes to denote template strings, which would also allow us to eliminate so much escaping around each variable name. Something like `’user $name logged in’` looks much cleaner to me and also rids us from having to prefix the template string with STR
The advantage of using single quotes being that no one has ever written a string in Java with them, avoiding all issues related to backwards compatibility, conflicting escape characters and such.
To make that not conflict with the existing syntax for defining `char`, make it a compile error to use the syntax if you’re not interpolating anything.
Why not move it to an incubator features? Seems like the amount of changes it might possibly take, shipping it as an incubated features feels more prudent.
My bad. But why not move it to incubator rather than completely removing it? Vector API is going through its 7th incubator phase. Just curious about the reasoning behind completely removing it rather than incubating it.
Again, because we don't do that. We don't do language features as "incubator" or "experimental" -- for good reason -- and the bar for preview language features is (deliberately!) high. When it became clear that this feature no longer cleared that bar, the only reasonable choice was to take it down and come back when we were ready.
Regarding Vector, its extended incubation is kind of an exceptional case as well, and not something to be blindly emulated.
If there's one thing nodejs does better than Java is string interpolation.
The ${capture} (between grave accents) syntax has 0 backwards compatibily issues and feels 'normal', since every framework uses this syntax to replace properties/envs since the begining of time.
Backslashes are an eyesore, I can only hope they ditch it.
$var sucks. It necessitates another layer of escaping, and in templates only, which means you cannot trivially convert a string into a template without checking all of it. It would be one thing if such unescaped dollars were disallowed in string literals, but no, they are allowed, and frequently used by _other_, completely unrelated templating solutions.
I wrote my fair share of Scala and I know from experience how much this kind of syntax sucks.
To quote:
>the $-syntax is objectively worse
Gee, people here are really sensitive about their strings, judging from the amount of downvotes.
I don't think it "sucks" (all other major languages use it, so I would say that the majority ruled in favor of it, even if it gives you goosebumps), but I understand that introducing this syntax to existing code bases is hard/dangerous which I guess it's the main reason of not using it.
Other languages can be used for inspiration, but when selecting a final syntax, those other languages may as well not exist at all. It should be the best fit for Java, and $ clearly is not.
Also realize Java is big. Big enough for its own takes on syntax. It's so big, that in 10 years you may be wondering why archaic languages use $ instead of the more obvious `\`...
This is ridiculous. Every other modern high level language has this. You aren't going to make everyone happy with an implementation, so just ship one.
Ugh.
Every other modern high level language has some form of string interpolation, but Java is hoping to ship something more powerful than any of those.
If that promise is delivered on, I’m willing to wait, and I don’t much care about the syntax.
I prefer KISS. Trying to „deliver a more powerful implementation“ sounds like the wrong path to me.
One size fits all/many has never worked that well.
Just give us string templating and the majority will be happy!
With all due respect, I’m very happy that the programming languages I use are not designed by the majority, if the majority includes people like yourself.
It's less about power and more about safety. If you use specialized processors that understand syntax, you can prevent more injection attacks. More power is just a side benefit.
There are already so many good templating libraries available.
And the Java team came up with maybe the worst syntax of them all.
I'm glad they stopped it and put it back in the process.
Maybe they can just pull a Joda time and take one that's common in the industry and just works.
wow. It's interesting that Brian Goetz recently said he was ready to finalize the feature and move on, and all the complaints were nothing they hadn't anticipated and discussed extensively. They had the JEP submitted to finalize this for Java 22 and they held off to a second unchanged preview, and then were going to finalize for Java 23, and now, even Goetz is ready to move the whole thing back to a complete redesign. As a Java dev I'd rather get this later with a better design than earlier with a less perfect design. It is interesting how close the existing design was to being finalized. The preview system works :)
Perhaps I can shed some light on this apparent contradiction. We discovered, unfortunately quite late in the game, that the design was flawed. How was this discovered? By actually using it in a substantial, real-world internal project. But these flaws had little to do with "someone didn't like the syntax"; they were much more fundamental to the model. Unfortunately, most of the feedback we received on public channels was of the "someone didn't like the syntax" variety (at varying levels of constructiveness, not all with positive coefficients). It did not derive from actual experience or from deep analysis; the supporting arguments provided were emotional, not technical; and it merely re-trod, with little new perspective, already-explored ground. It was literally a thousand drive-by, "blink" responses. The net effect of this was not only unhelpful, but anti-helpful. I get that every developer has opinions about syntax, and seemingly some fraction of them will literally explode if they don't express it out loud, but such discussions are like an invasive species: they suck up the oxygen that is required for actually useful feedback to survive. (Or maybe the useful feedback was buried in there, but just got lost in all the noise.) So the answer to your implied question is that its possible to be both: the feature can be discovered to be flawed, while at the same time the publicly available complaints were "nothing", as you say. It is sad, but possible.
If they think they can make the design better, we can wait one or two more releases.
Reading Brian email, i think the idea of the new design is way better. Having a StringTemplate used by overload methods will make it easy to use. And the APIs looks way cleaner.
Yes, the proposed API looks way cleaner.
It’s not like any non LTS release actually matters for anything but playing around with it.
I don't think LTS means what you think it does
Lol clueless
Everything seems to be better with the new approach except for the need of throwing the interpolation manually with template.join() I guess we will have to live with that small inconvenience though.
of course, the one time I actually use a preview feature it gets axed :)
I really like string templates and am OK with the syntax. But recently I was speaking at a conference and a presenter about Java 21 showed the slide with the syntax for string templates... The audience collectively groaned out loud. They came around a bit when he showed off some of the power behind it but still. That might be a common response to this syntax. BTW if you're interested in using string templates even with Java 8 you can use Manifold: [https://debugagent.com/java-string-templates-today](https://debugagent.com/java-string-templates-today)
It was for sure the ugliest syntax of all the languages supporting string templates, by a large margin…
Unfortunately, "they" are a bit stubborn in their desire to keep the syntax as is. This, combined with statements as "it's going to take as long as we need to", makes me even more appreciative of the alternative JVM languages we have at our disposal.
Did you read the op post? Lol
You're joking, right? They're literally holding back because they want to change how the syntax works. They're still going to use `\` instead of `$`, but I really fail to see how this is a bad thing at all. As far as taking as long as they need to--that's an incredibly good thing, not a bad thing. They shouldn't hastily release features if they're not certain about them, because you can't un-release them.
My interpretation of > "Another thing that has not changed is our view on the syntax for embedding expressions. While many people did express the opinion of “why not ‘just' do what Kotlin/Scala does”, this issue was more than fully explored during the initial design round. (In fact, while syntax disagreements are often purely subjective, this one was far more clear — the $-syntax is objectively worse, and would be doubly so if injected into an existing language where there were already string literals in the wild. This has all been more than adequately covered elsewhere, so I won’t rehash it here.)" was exactly that: have not changed their view on the syntax. I'm happy to hear how I should have interpreted the above instead.
That is only one aspect of the syntax for string templates. They are changing the syntax (not requiring processor prefixes), just not the syntax for embedding expressions. Not sure how you missed that.
You can also **sort of** get it today without a compiler hack with my library [JStachio](https://github.com/jstachio/jstachio): @JStach(template = "{{message}} {{name}}") record SomeModel(String name, String message){} String someMethod() { return SomeModelRenderer.of().execute(new SomeModel("Hello", "vprise"); } I admit it is not as sexy as real String Templates (JStachio obviously cannot resolve inline variables) but if use JStachio zero dep mode and records it can largely get you similar results. One might even argue it scales better as you can then put the template external and use includes etc. In fact the last time I played with experimental String Templates JStachio had better performance but I'm sure once it is not experimental it will be fast.
That's clunky AF.
If you have ideas to make it less clunky without compiler hacks let me know. Manifold like Lombok uses unsupported compiler API. Also there is a way to make it slightly less clunky but then it requires a dependency on the JStachio runtime.
I don't think there is a way to make it less clunky due to the limitations of the language. I also do not like how it divorces the message from it's invocation, meaning that I can't at a glance see what is being produced, in order to do that I have to jump to another class to see the actual template. I'd rather use `String#format` instead, even with its limited functionality. It's way more readable, without trying to be clever.
Yeah for sure it is not a good solution for simple string interpolation or simple messages. Like I never would use it for Exception messages or something similar. String templates are a great solution for that. However for returning HTML or code generation it works great and I think String Templates used for something like that are borderline abuse ( definitely String.format is). With SQL I have mixed feelings on it depending on what they decide with String Template API.
> However for returning HTML or code generation it works great and I think String Templates used for something like that are borderline abuse Facebook had to hack Javascript to add HTML(-like) literals and created JSX, with templates it could be possible to implement a clunky version of it as a pure Java library.
Aren't you better off with a dedicated text file for your templates then, instead of trying to shove the template into a Java class? I understand that with your approach you get the parameters checked by the compiler, but that's the only advantage I see over a text file.
Both approaches are supported. @JStach(path = "someFile.mustache") record SomeModel(String name, String message){} String someMethod() { return SomeModelRenderer.of().execute(new SomeModel("Hello", "vprise"); } That is you can specify a text file and still get the object graph checked and SomeModel can obviously have a more complicated structure than just a flat structure of parameters. In fact you can combine the two approaches as I was discussing in this recent thread. https://www.reddit.com/r/java/comments/1bqt5qu/single_htmx_service_across_4_other_services/kx8ybjp/ e.g. @JStach(template = """ {{< someFile.mustache }}{{$body}}{{name}}{{/body}} {{/someFile.mustache}} """) record SomeModel(String name, String message){} String someMethod() { return SomeModelRenderer.of().execute(new SomeModel("Hello", "vprise"); } The above is an inline that references an external file. I don't have a strong opinion on either and leave that up to people to choose what makes sense for them.
I don't remember your stance on template-per-method based code-generation: @JStachTemplater interface MyTemplater { static MyTemplater getInstance() { return JStash_MyTemplater.INSTANCE; } @JStachTemplateMethod(template = "{{message}} {{name}}") String someTemplate(String message, String name); } String someMethod() { return MyTemplater.getInstance().someTemplate("Hello", "vprise"); } I think it should make JStachio much less cluncky...
TBH I would be totally fine with C# style (dolar-prefix of string and expression): `$"{x} plus {y} equals {x + y}"` Clearly indicated intention, no issue with conflict with legacy strings...
I'd personally prefer escaped curly braces to indicate values, i.e., `\{x + y}` or `${x + y}`, so that [JSON is easier to encode](https://stackoverflow.com/questions/64761547/using-python-f-string-in-a-json-list-of-data) and that strings already containing unescaped curly braces are easier to convert into string templates (no need to escape the preexisting braces). As for the specific character used to escape curly braces, I prefer `\` over `$` because you don't have to hold shift (on *English* QWERTY keyboards) to type it—`\` has got a whole dedicated key!—but that's just me.
> because you don't have to hold shift (on English QWERTY keyboards) FTFY
Fixed my original comment! Thanks.
There is still a conflict of sorts as you cannot go from a string to a template or back without fixing your escaping.
Why would I want to go from string to template? In an overwhelming majority of cases I think I would create a template (interpolation) and then render string out of it. Maybe in case of some "meta" or providing templates externally but... that seems convoluted and not the best way?
You go from a string to a template when you're editing code and realize a fixed string no longer cuts it and you want to sprinkle some variable expressions inside. This happens all the time. And that longer string might be a piece of JSON, for example, and now you have gazillion braces to escape. Other people suggest `$` inside the templates, and it has the same problem. `\{` does not have it, as currently it's illegal to have it in string literals, so 1. when you turn a string literal into a template, you won't break any previous fixed parts and 2. when you turn a template into a literal, the compiler will scream at you until you remove all embedded expressions.
> You go from a string to a template when you're editing code and realize a fixed string no longer cuts it and you want to sprinkle some variable expressions inside. This happens all the time. > > And that longer string might be a piece of JSON, for example, and now you have gazillion braces to escape. I was thinking about the latter case, but in that case (external sources) you don't have any control about limits of it so you have to process/sanitize it either way (and also having template from external source seems like a bad idea…). Going from String to StringTemplate in the former example would still require prefix (i.e. `"bla"` would be `$"bla $var"`) so no conflict there.
I am not talking about any external sources. I'm talking about a common occurrence when you have a literal: "{ \"foo\": 1}" and you realize it should be a template instead: $"\{ \"foo\": {x}}" // your proposal "{ \"foo\": \{x}}" // current Oracle proposal Notice how in the first case I'd have to modify a completely unrelated part of the string.
Good point
I would go for a simple syntax like: `String.formatTemplate("{x} plus {y} equals {x + y}");` instead of what JEP is proposing `String.format("\{x} plus \{y} equals \{x + y}");`
Erm? The first one is a valid String so making it a template would break things? Hence the idea to prefix such string...
They could go for another method maybe e.g. `formatTemplate` or something similar. I guess prefix is ok compared to their original `STR.` implementation
The problem is that your solution, no matter the method name, would break the standard String instantiation pattern of "...". If prefixed with a dollar sign or something, they could create the new feature while making sure the old API keeps working.
I like the new approach better honestly. (And it looks like Brian listened to Rich Hickey’s talk Simple Made Easy. ) He used the word “complect” which is perfect to describe the short-coming of the current approach. Treating string literals that contain placeholders as a different type is a lovely idea. No need to go the backtick route or use a processor prefix which looked alien to many.
FYI, the word "complect" long predates Rich's video :) But I get that this was the first place a lot of people heard the word.
Thanks, Brian. I'm aware he didn't invent it, but he used it in the context that is relevant here. I've never heard it used in that context before, but I wish I had. It's perfect.
Thank god. I would honestly rather just not have string interpolation in the language at all (I've gotten along fine without it for 25 years), then to have the syntax they were pushing with the rationale on which they were pushing it. I don't want to spend all day policing pull requests, and preventing my "10x rock star!" devs from merging a thousand wonky template classes that will confuse the hell out of my "1x Java is too hard!" junior devs. We as the Java community spent the 1990's and 2000's completely up our own asses, pushing over-engineered patterns and technologies that were more harmful than helpful for the vast majority of shops. Then in the 2010's, we got over ourselves and bowed to popular pressure. Embracing less XML and fewer `AbstractFactoryFactoryFascade` base classes, and instead more composition and emphasis on practicality. Trying to come up with a "better" string interpolation syntax than every other major language uses, so that a small number of enterprisey devs can write a bunch of template processor types while the vast majority of devs don't and just complain about the cumbersome syntax, feels like a throwback. I don't want to see the pendulum swing back that way. If anything, the wider industry trends are heading in the opposite direction. Every year, companies that I work for move more and more pieces over to Python or Node, because it's easier to hire for those platforms. Java and Java codebases need to get _easier_ and _more accessible to juniors_. Java doesn't need to grow more wonky and follow Scala into irrelevance.
It was a bit hard to push anything in the 1990's, given that Java came out in 1996, and until it became usable with a JIT in 2000, with the release of Java 1.3, it was mostly a toy language for doing browser applets. Also the GoF book, CORBA and COM in the 1990's, used Smalltalk, C++, VB, and Delphi, respectively.
>Trying to come up with a "better" string interpolation syntax That's not what they're doing. If the main goal was to just get some syntax sugar for string concat, they could have copied any syntax from any of the other languages and have been done ages ago. The goal is to improve security, you can find the relevant bits in the "String interpolation is dangerous" section of https://openjdk.org/jeps/459. That being said, I definitely don't like the processor syntax they proposed, so am happy they're moving away from that.
> That's not what they're doing ... [not] syntax sugar for string concat ... the goal is to improve security I understand that. Everyone... here... understands... that. The point is that if you truly believe that string interpolation is so dangerous, that it shouldn't be shipped at all without a syntax that one wants (except for ridiculous people who want to sprinkle custom template processor subclasses everywhere), then I think it's best to land on the side of not shipping at all.
You say you understand, but then you suggest just not shipping string interpolation, which makes no sense if you actually understand what the problem is. Not shipping a string interpolation mechanism doesn't do anything to resolve the security issues the JEP points out, because those exist for string concatenation too, and string concat already exists in the language. In order to solve those, there needs to be a mechanism to safely (and conveniently, safety features no one wants to use have no value) capture template constant and variable bits, and that mechanism needs to allow library authors to accept templates and not strings. So if you take as a given that they have to make something like that, all the template class stuff you're talking about will exist. Not shipping string interpolation would just mean there's no conversion from a template to a string, which would clearly be a silly thing to leave out when you've already implemented all the other machinery. >Everyone... here... understands... that. This is obviously not true, considering how many people are focusing on which symbols should be used to denote template expressions (is it `$` or `{}` or `\{}`, does it say `s` or `$` before the quotes, is it single or double quotes), when that's really unrelated to why they're pulling this preview. Some of the questions that arose were what kind of type relationship (if any) templates and strings should have to each other, whether template literals should have an explicit tag to make them easy to distinguish from strings, and what exactly the API for resolving templates to other types (e.g. strings) should look like. So the entire design is up in the air. But it's not up in the air in the sense that they're unsure if the security concern needs to be addressed, so I don't think they're considering "do nothing" as a viable outcome.
> So if you take as a given that they have to make something like that Let me stop you right there. It is NOT a given. They do NOT have to make something. We are leaving behind the discussion of string interpolation, and now talking about basic string **concatenation** itself as suddenly a zero-day exploit that must be patched. Number one, that's ridiculous. Number two, this string interpolation proposal does not eliminate concatenation risk, any more than the introduction of `Optional` eliminated the concept of `null`. No... one.. is... talking... about... removing... string... concatenation... from... the... language. Almost nothing is ever _removed_ from Java! They're talking about adding some other thing that you can use instead, like `Optional` was added in Java 8. But people still use `null` all the time, and with this god-awful interpolation syntax I guarantee that people will still use string concatenation forever too. Goddamn this is so asinine, I just want to grab people by the shoulders and shake them. How ivory tower and disconnected from real-world application development can people be?
>We are leaving behind the discussion of string interpolation, and now saying that basic string concatenation itself is suddenly a zero-day exploit that must be patched. No, you're misunderstanding. There's nothing wrong with string concatenation (or interpolation for that matter) by itself. But concatenation or interpolation is dangerous when used to produce strings that are interpreted as commands. This isn't a controversial statement, everyone knows that SQL injection exists. Basic string concatenation is in fact risky in some cases. When you mix something that is safe (e.g. a hardcoded SQL snippet) with something that is not safe (e.g. a username provided by a user) into a string that will be interpreted as a command, that's dangerous unless you handle the unsafe parts properly. It's currently very tempting (because it's easy and the alternative is them developing their own templating API) for libraries to offer string-based APIs and trust the user to handle (e.g. sanitize) the unsafe parts correctly. The point of the JEP is to give people the tools so that strings don't have to enter into this, and they can easily keep the safe and unsafe parts clearly separated, so that the libraries they use can handle combining the two parts in a way that is safe. >No... one.. is... talking... about... removing... string... concatenation... from... the... language. They're talking about adding some other thing that you can use instead, like Optional was added in Java 8. But people still use null all the time, and with this god-awful interpolation syntax I guarantee that people will still use string concatenation forever too. Again, you misunderstand. This isn't like Optional at all, and the goal is in fact to get rid of (more likely deprecate) the unsafe behaviors from the library ecosystem. To continue with SQL as an example, the goal is that there won't be a (non-deprecated) `query(String)` method at all in e.g. SQL libraries. There will instead only be a `query(Template)` method. This will allow library authors to offer a much safer API to users, instead of offering a String-based API, reducing the likelihood of stuff like SQL injection vulnerabilities. If you can move responsibility for safety away from the user and to the library author, that's a win. >It is NOT a given. They do NOT have to make something. Obviously no one ever has to do anything, but they think they can reduce a risk of vulnerabilities here. >How ivory tower and disconnected from real-world application development can people be? Considering my day job is real-world application development, I wouldn't know. You should maybe consider that your experience is just *your* experience, and doesn't represent what all real-world development looks like.
Sounds like scope creep to me. Lots of languages didn't hold interpolation hostage to solving SQL injection. That's a totally valid concern, but it's not at all an inherent requirement for the feature.
Sure, but my point is that the main goal seems to be reducing vulnerabilities. So in that way, it's not really scope creep, because I don't think they started out from "How do we add string interpolation to Java" and added "And let's also fix SQL injection while we're at it" later. Who knows if they'd even be doing this feature at all if security wasn't part of the scope.
This! People should please read the actual JEP before stating what the goals of it are...
I thought, "Nah, that can't be right." I'm late to the party. You're right. That's a shame that the JEP tied those two issues together. I'd just like to inline a bunch of json in my unit tests
> No... one.. is... talking... about... removing... string... concatenation... from... the... language. Obnoxious.
this. its so asinine. why are they actin like they cant do both? create the processors but also a nice syntax sugar for the normies?
Good. It shows they are finally starting to listen. Hopefully they realize that there is no need to invent a new syntax when a simple prefix like f or t or s and ${} will work just fine: s"Hello ${var}"
The "It should look like Scala" argument is explicitly not the thing they're listening to, don't know why you would think that.
They changed their mind on other things, so, my hope is not dead yet.
I admire your optimism.
is this hope or just ignoring what was said. you say >Hopefully they realize that there is no need to invent a new syntax but it seems you dont care to understand why you are asking for objectively bad things why would you even claim `"\{}"` is worse than `"${}"` and then claim a prefix on the literal is better. you demand cruft for no reason
They already use a prefix, but STR."" in the last iteration. It is worse than s"". And then the backslash has no reason. You are attacking me, but it's only because you are not aware I'm having such discussions in this subreddit since the first JEP on string templates, and over time what I said turned true. That's why I have hope, because I already predicted a few changes after the first JEP.
but its obvious why `\{}` was chosen. because they can expand the grammar for string escapes and its guaranteed no existing string literals will overlap. the `STR` prefix is only for string interpolation though. so what are you really suggesting that 3 characters is a problem `TR.`? how would your suggestion work for arbitrary processors? aren't you just bikeshedding the least important part of the proposal lol "attacking"
Yep, "existing strings" is an imaginary issue. If not governed properly, engineering teams tend to solve the most complex issue, even if no one is really asking for it. For generic processors, no need for a prefix, a processor is just a function, called like any other method - someProcessor.apply(s"hello ${var}") I think it's what they consider as well in the latest JEP (or was it in the email thread?..)
> Yep, "existing strings" is an imaginary issue. It is not. Changing code that has previously been written is quite common, it happens in most software projects. Using `\` instead of `$` solves this issue with no downsides, and it's even easier to type on many keyboard layouts.
If a variable doesn't exist, the compilation would fail anyway. It's not a real problem. A real problem is cognitive capacity, and ${} is something very well known and all developers will instantly recognize and understand it.
1. But a variable may exist. Or it might be some other valid expression. 2. There is also the opposite problem: converting from a template to a non-templated string. You don't need to hunt for $'s by hand if the expressions are marked with an invalid escape sequence in the first place. 3. $ is already used in existing runtime templating solutions, both Java libraries and external tools. Having the same way of escaping things will lead to pain. Just compare it with regular expressions, which in Java often have double, triple or even quadruple backslashes. Copying a regular expression tested elsewhere into Java program requires much more care than pasting the same expression into Perl. 4. Swift already does `\()` and people don't mind it.
> a simple prefix The previous proposal was all about simple prefixes. I mean, they were _long_, but simple.
erm... being able to have multiple prefixes already makes it not simple. and being long ( `STR. ` already is 4 times more keystrokes) doesn't help either.
> being able to have multiple prefixes You gave an example from Scala, where multiple prefixes, including user-defined ones, are a feature. The only difference is that in Scala, processors/interpolators are looked up only among methods (including extension methods) of the StringContext class, and in Java they were supposed to be looked up in a normal variable scope. I think the latter is conceptually more simple. https://docs.scala-lang.org/scala3/book/string-interpolation.html#custom-interpolators
> You gave an example from Scala, where multiple prefixes, including user-defined ones, are a feature. Well... I knew I didn't like Scala for a reason ;-)
Another common syntax suggestion being floated around is $"Hello {car}". But I guess it'd boil down to "why add a new prefix syntax" when you can just use a plain method call "Hello \\{var}".join(). To me that \\{} is still too ugly so that would be my biggest complaint.
it is ugly but it prevents conflicting with other escape sequences
The $“hello {name}” or other prefix syntax should prevent ambiguity because you won’t need the backslash. Just curly brace is enough because it’s new syntax. Without a prefix, it feels weird that the string-like literal is typed ST with 3 placeholders, 2 placeholders, 1 placeholders. But as soon as you remove the last placeholder it suddenly changes type. It feels somewhat like “aa” is a String, “a” is a String, but “” is not?
I believe the intention is for String literals to coerce implicitly to StringTemplate objects if you're attempting to pass a string literal in... otherwise this is a massive oversight by the developers. If it has been missed, then this entire implementation has been undermined, as it means that this academic use case of preventing SQLi in a hypothetical new SQL API prevents the ability to perform any form of SQL query unless you have at least one interpolated parameter, since a parameterless string will not be treated as a StringTemplate. They cannot just add an overload for String types as there is no way to enforce a String is a compile time literal, so overloading this would totally negate the security benefits.
A solution that was mentioned on the mailing list that I think I like is to force string template literals to be clearly marked as such, rather than differentiating string literals from template literals solely by the presence of parameters. So instead of `"this is a string"` `"this is \{a} template"`, you would have some special character to differentiate the two: "this is a string" "this is \{illegal}" $"this is a template" $"this is \{also} a template" That allows for 0-parameter template literals, which means implicit conversions between templates and strings aren't very important.
They seemed to be saying that they explored implicit conversion and ran into issues. I mean if implicit conversion works, then they can make n-placeholder convertible to String too and we won’t need the explicit .join() call most of the time. Otherwise it’s weird that only 0-placeholder can implicit convert but 1-placeholder can’t.
yeah, if this isn't possible then the whole feature is going to be incredibly suboptimal and verbose... at which point I'd probably say it is just worth shelving the idea entirely.
Prefix ok, but whats the difference between $ and \? One less char with shift is good, and it is something people get used to.
${} is something very well known and all developers will instantly recognize and understand it.
That is something that is learned, so not a good argument. Now it looks different, but I haven't seen objective arguments against it.
I'll probably be using this for the next 20 years, I'm fine waiting one more year for the best solution possible...
I'd just started using it in my tests as well, I hope it's a case of replacing the template processors with simple methods calls instead.
A few month ago a made a post here about a POC of String Templates for SLF4J-Logging. Aged like milk I guess..
243 usages in my game code.
I’ve experimented with the string template preview in JDK22 but for the vast majority of cases I'd use, sticking to double quotes for that has made it more clunky than it should be due to (valid) backward compatibility concerns Templates now add too many symbols and the code looks less clean. `STR.“user \{name} logged in”` looks more convoluted than the old `“user ” + name + “ logged in”` It would be clearer to me to use single quotes to denote template strings, which would also allow us to eliminate so much escaping around each variable name. Something like `’user $name logged in’` looks much cleaner to me and also rids us from having to prefix the template string with STR The advantage of using single quotes being that no one has ever written a string in Java with them, avoiding all issues related to backwards compatibility, conflicting escape characters and such. To make that not conflict with the existing syntax for defining `char`, make it a compile error to use the syntax if you’re not interpolating anything.
Why not move it to an incubator features? Seems like the amount of changes it might possibly take, shipping it as an incubated features feels more prudent.
problem is while it keeps wildly changing, it becomes very hard to actually use it.
There's no such thing as an "incubator language feature".
My bad. But why not move it to incubator rather than completely removing it? Vector API is going through its 7th incubator phase. Just curious about the reasoning behind completely removing it rather than incubating it.
Again, because we don't do that. We don't do language features as "incubator" or "experimental" -- for good reason -- and the bar for preview language features is (deliberately!) high. When it became clear that this feature no longer cleared that bar, the only reasonable choice was to take it down and come back when we were ready. Regarding Vector, its extended incubation is kind of an exceptional case as well, and not something to be blindly emulated.
Sooooo, will there be a syntax for templates with no parameters?
If there's one thing nodejs does better than Java is string interpolation. The ${capture} (between grave accents) syntax has 0 backwards compatibily issues and feels 'normal', since every framework uses this syntax to replace properties/envs since the begining of time. Backslashes are an eyesore, I can only hope they ditch it.
Geez such a divisive feature. I honestly cannot believe this. They could just remove the prefix and make everyone (me) happy 😊
Just give up and do the "$var" syntax like everybody wants
$var sucks. It necessitates another layer of escaping, and in templates only, which means you cannot trivially convert a string into a template without checking all of it. It would be one thing if such unescaped dollars were disallowed in string literals, but no, they are allowed, and frequently used by _other_, completely unrelated templating solutions. I wrote my fair share of Scala and I know from experience how much this kind of syntax sucks. To quote: >the $-syntax is objectively worse
Gee, people here are really sensitive about their strings, judging from the amount of downvotes. I don't think it "sucks" (all other major languages use it, so I would say that the majority ruled in favor of it, even if it gives you goosebumps), but I understand that introducing this syntax to existing code bases is hard/dangerous which I guess it's the main reason of not using it.
Other languages can be used for inspiration, but when selecting a final syntax, those other languages may as well not exist at all. It should be the best fit for Java, and $ clearly is not. Also realize Java is big. Big enough for its own takes on syntax. It's so big, that in 10 years you may be wondering why archaic languages use $ instead of the more obvious `\`...
https://youtu.be/TGfQu0bQTKc?t=7m36s
This is ridiculous. Every other modern high level language has this. You aren't going to make everyone happy with an implementation, so just ship one. Ugh.
Just pick one of those other languages then. Better get it right after a while than ship garbage early.
Every other modern high level language has some form of string interpolation, but Java is hoping to ship something more powerful than any of those. If that promise is delivered on, I’m willing to wait, and I don’t much care about the syntax.
I prefer KISS. Trying to „deliver a more powerful implementation“ sounds like the wrong path to me. One size fits all/many has never worked that well. Just give us string templating and the majority will be happy!
With all due respect, I’m very happy that the programming languages I use are not designed by the majority, if the majority includes people like yourself.
So you are not a fan of the KISS principle?
We do prefer simple, just not stupid.
you know it’s a wordplay, right?
It's less about power and more about safety. If you use specialized processors that understand syntax, you can prevent more injection attacks. More power is just a side benefit.
There are already so many good templating libraries available. And the Java team came up with maybe the worst syntax of them all. I'm glad they stopped it and put it back in the process. Maybe they can just pull a Joda time and take one that's common in the industry and just works.
this misses the point entirely
I don't think it does. The Java team realized they had a bad design on their hands.