JEP 430: String Templates (Preview) Proposed to Target Java 21
1–10 of 246 posts
Re: JEP 430: String Templates (Preview) Proposed to Target Java 21
#2A bit ugly, but seems powerful. Very similar to tagged template literals in JS.
Re: JEP 430: String Templates (Preview) Proposed to Target Java 21
#3 String name = "Joan";
String info = STR."My name is \{name}";
Re: JEP 430: String Templates (Preview) Proposed to Target Java 21
#4I am legit impressed, and I say this as one who has been very hard on string interpolation in other languages; see https://www.jerf.org/iri/post/2942/ and the matching https://pkg.go.dev/github.com/thejerf/strinterp#section-read... for instance. I have criticisms most developers don't even think about.
This isn't exactly what I laid out, of course, but I think it achieves the goals I was looking for, which is the real issue. In particular, having the default string interpolation be prefixed with "STR." is enough for linters and scanners to get a chew on (it's easy by scanner standards to track that a STR.-interpolated string got fed into a database query), and for code reviewers to develop an instinct to look at such interpolations more closely than they need to for a DB. interpolation. An STR annotation is not technically necessary for the former, if it were simply the default, but it is a big deal for the latter. I want people to have a chance to notice and think about their use of bare string interpolation for at least a fraction of a second as they type "STR." (or autocomplete it or whatever).
This does put a heavy burden on the libraries to implement it correctly, but if they do it's even safer than what I was thinking.
One thing though: Please for the love of the internet, for those of you writing interpolators, DO NOT write an interpolator that picks apart the values passed in through a \{ ... } and starts instantiating arbitrary classes via Java reflection. Just stay away from that entirely, OK?
Re: JEP 430: String Templates (Preview) Proposed to Target Java 21
#5Are they trying to make Scala look more complicated than the other languages on purpose? The Scala example f"$x%d plus $y%d equals ${x + y}%d" could be written simply as s"$x plus $y equals ${x + y}"
Re: JEP 430: String Templates (Preview) Proposed to Target Java 21
#6String name = "Joan"; String info = STR."My name is \{name}"; I don't love it, to be honest. `STR` is a bit much. Requiring the \ for the first but not second brace. I want string templates in Java, but this feels ugly.
Yeah, the choice of \{ to create an expression instead of printing a literal { character is an odd one when you compare how you output a double-quote character:
> To aid refactoring, double-quote characters can be used inside embedded expressions without escaping them as \".
I would expect for consistency that \"{expression}\" outputs an expression and \"\{expression}\" would not.
Re: JEP 430: String Templates (Preview) Proposed to Target Java 21
#7I am legit impressed, and I say this as one who has been very hard on string interpolation in other languages; see https://www.jerf.org/iri/post/2942/ and the matching https://pkg.go.dev/github.com/thejerf/strinterp#section-read... for instance. I have criticisms most developers don't even think about. This isn't exactly what I laid out, of course, but I think it achieves the goals I was looking for, which is the rea…
I guess it's an advantage of playing catch-up. You can learn from other languages their experience and mistakes.
Still props for the Java team for doing a good job.
Re: JEP 430: String Templates (Preview) Proposed to Target Java 21
#8String name = "Joan"; String info = STR."My name is \{name}"; I don't love it, to be honest. `STR` is a bit much. Requiring the \ for the first but not second brace. I want string templates in Java, but this feels ugly.
[dead]
Re: JEP 430: String Templates (Preview) Proposed to Target Java 21
#9String name = "Joan"; String info = STR."My name is \{name}"; I don't love it, to be honest. `STR` is a bit much. Requiring the \ for the first but not second brace. I want string templates in Java, but this feels ugly.
Im guessing that the second backslash was deemd unecessary (and in my opinion it is - no need for additional key strokes in the name of some arbitral consistancy).
Besides you are probably looking at this wrong - backslash here is equivalent of hash or dolar sign - it denotes begining of expression (just like most languages do). And they literally could not use another one because of backward compatibilty it they want to keep the "no STR"/simple versuon of interpolation possible. They will just add new escape sequence /{ - its kinda brilliant if you think about it.
Re: JEP 430: String Templates (Preview) Proposed to Target Java 21
#10What happens if I already have a field called STR or FMT?
> STR is a public static final field that is automatically imported in every Java source file.