Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JEP 430: String Templates (Preview) Proposed to Target Java 21

openjdk.org

Post reply on HN
Print view View original

11–20 of 246 posts

Re: JEP 430: String Templates (Preview) Proposed to Target Java 21

#11

Post by pron »

mabbo wrote: post #3

String 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.

STR is not some special syntax, just a receiver for a method call. You would only need STR to interpolate a template into a String, but any receiver can specify that interpretation of the template -- or a different one. So, for example, a logger could use:

    log.info."x: \{x}";
and similarly for other uses that don't produce strings but JSON, SQL etc. So STR would only be used -- hopefully rarely -- for old APIs that have not determined their own template interpretation strategy and only accept String.

The use of the backslash is important to distinguish between a string literal and a template literal because "x: \{x}" is not a valid string literal today. Swift uses \(...), BTW.

Re: JEP 430: String Templates (Preview) Proposed to Target Java 21

#12

Post by Alupis »

mabbo wrote: post #3

String 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.

It is indeed ugly. Having switched full-time to Kotlin a little less than a year ago, I honestly prefer their approach to String interpolation using `${var}`.

I understand Java has a backwards compatibility issue that Kotlin does not though, which would make breaking changes to all the hard-coded strings containing `$` that would now need to be escaped. This is discussed in the JEP.

Backwards compatibility - simultaneously Java's strongest and weakest asset.

Re: JEP 430: String Templates (Preview) Proposed to Target Java 21

#13

Post by pron »

jsiepkes wrote: post #7
jerf wrote: post #4

I 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.

Back in 1997, when James Gosling outlined his vision for Java, he said it should be a conservative language (wrapping a very innovative runtime) that would ideally only adopt features that have proven themselves, for some time, in other languages. Being a last mover is at the very core of Java's evolution strategy. It's not playing catch-up because we're not trying to adopt all features other, more "adventurous", languages have, but rather to selectively pick the fewest features that would have the biggest impact. That's the aspiration, at least.

Re: JEP 430: String Templates (Preview) Proposed to Target Java 21

#16

Post by geodel »

lanna wrote: post #5

Are 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}"

Yes, Java is legit scared of Scala's rising popularity.

Re: JEP 430: String Templates (Preview) Proposed to Target Java 21

#17

Post by nezirus »

That database stuff looks horrible. Why do they feel the need to introduce DB query templating into string templates? No matter what you do on the client side, the database engine itself should escape/validate the data. Didn't we learn that lesson with PHP?

In addition to that, not every database needs prepared statements for safe queries e.g. "Parametrized queries" in PostgreSQL (available in libpq as PQExecParams and exposed in many other higher level languages)

Re: JEP 430: String Templates (Preview) Proposed to Target Java 21

#18

Post by geodel »

supriyo-biswas wrote: post #14

The proposal is uglier than f-strings in Python. A better approach would be to use backticks like JavaScript does.

As long it is technically solid, ugly is just fine in places where Java is used most. Even if it were most lovely syntax Python/JS devs are not gonna jump to code in Java.

Re: JEP 430: String Templates (Preview) Proposed to Target Java 21

#19

Post by ndriscoll »

lanna wrote: post #5

Are 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}"

It's funny too because the Scala ecosystem has had safe string interpolation for years. e.g. with Slick sql"SELECT * FROM Person p WHERE p.last_name = $lastName" will produce a parameterized query/prepared statement that you can run, and it does this at compile time so runtime injection like log4shell is impossible.
Post reply on HN