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

71–80 of 246 posts

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

#71

Post by Kwpolska »

kaba0 wrote: post #52
_old_dude_ wrote: post #32

Earlier quoted context omitted.

That's why JS use ` and not reuse ". You want the lexer to be able to make the difference between a constant string and a template string and you want users to be able to read the code. This JEP solves the former not the later.

It’s not as bad as people make it out to be. Swift without any backwards compatibility constraints chose “\(val)”. It does need a slight getting used to but it is not any worse than ${}.

Swift’s choice is strange and ugly IMO, even if it did not involve backwards compatibility constraints.

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

#72

Post by pron »

Bjartr wrote: post #37
pron wrote: post #11

Earlier quoted context omitted.

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 h…

> So STR would only be used -- hopefully rarely If that's the hope, why have it automatically imported statically for all files?

Because it doesn't hurt, and because it will take some time until all relevant libraries expose their chosen template processor, reducing the need for STR, the tax on less restrained uses needs to be neither too high nor too low.

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

#73

Post by nezirus »

bcrosby95 wrote: post #58
nezirus wrote: post #17

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 a…

The database stuff looks like an example, and shows how you could extend the template system in a way that doesn't introduce security problems.

That is exactly the point, you should not use general string templating system for SQL queries, together with "roll your own" escape and validation mechanisms. I really don't see why they included that part, if not to show how to shoot yourself in the foot.

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

#74

Post by aardvark179 »

spankalee wrote: post #41

This looks great. I maintain the lit-html template library which uses JavaScript tagged template literals to embed HTML in JS. A key feature of JS template literals is that the tag receives the string fragments and values separately, and can return non-string results. This means we can escape values and validate template structure to prevent XSS attacks. This approach in Java should lead to a lot more lightweight but…

This spec doesn’t need to specify that as it should fall out naturally from Constable and co (JEP 303 and 334) in combination with string templates.

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

#75

Post by lenkite »

kaba0 wrote: post #56
The_Colonel wrote: post #53

Earlier quoted context omitted.

Right, and that's why Java introduced checked exceptions in 1.0. A feature which wasn't proven back then and remains unproven now. Another example being overengineered streams. Parallel streams look really cool as a demo, but have been proven dangerous in their default configuration (they can exhaust the default thread pool).

Checked exceptions are exact analogs to Result types, but better (auto-unwrap, bubble up, stack traces). It is unfortunately far from flawless (inheritance is not a great combo with it), but that has been part of the language since the beginnings. Streams are not a language feature, it is only a library. And I honestly don’t find them over-engineered, they really make plenty of logics very readable.

Pity that the Streams functions don't support checked exceptions.

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

#76

Post by bcrosby95 »

nezirus wrote: post #73
bcrosby95 wrote: post #58

Earlier quoted context omitted.

The database stuff looks like an example, and shows how you could extend the template system in a way that doesn't introduce security problems.

That is exactly the point, you should not use general string templating system for SQL queries, together with "roll your own" escape and validation mechanisms. I really don't see why they included that part, if not to show how to shoot yourself in the foot.

There is no roll your own escape mechanics. The example uses prepared statements.

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

#77

Post by lenkite »

qw wrote: post #48
Noe2097 wrote: post #22

Why oh why is that a backslash!? Over the 9 languages mentioned: 5 languages (inc. JVM ones like groovy and kotlin) are using `$`, 1 language (swift) is using `\`. `\` is a pain to type on many keyboard layouts -- actually most but the US one. It seemed to me that `$` would have been a much more "conventional" choice. This really makes me sad. It looks like the choice was made on purpose to be different.

I agree. On my keyboard I need to press ⌥ + ⌘ + 7 It's actually made worse because { and } also need special combinations. To type \{X} I need to press (⌥ + ⌘ + 7) (SHIFT + ⌥ + 8) X (SHIFT + ⌥ + 9) I know this is something we need to live with due to historical reasons, but I would prefer that new syntax is made simpler.

What about parenthesis () and square brackets [] ? (writing a lisp DSL that might have users from non-US layouts)

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

#78

Post by Kwpolska »

pron wrote: post #63
Kwpolska wrote: post #46

Earlier quoted context omitted.

Python is also widely used server-side, and they introduced f-strings with simple and friendly syntax a few years ago. JS added template literals in 2015’s ES6, when Node.js was very much a thing. Why is Java special here?

Java's syntax is just as friendly and simple -- see my other comments on the subject -- it just requires the receiver to define a policy, which is essential for security. You only need to use STR when the receiver does not define a template processor and works with strings. I have no idea what Python's or JS's security experts advised, but that code injection is one of the most common vulnerabilities in memory-safe l…

I’m not a fan of the special `log.info."x: \{x}";` syntax, it looks like a weird mix of field access and a string literal.

And even with the fancy new syntax, I’m sure there will be people passing STR."SELECT * FROM x WHERE y = \{y}" to their database. You can educate people all you want, but not all developers will read the docs telling them this is dangerous. Even if all the docs do the right thing, people might end up reading old tutorials, and will then notice the “inefficiency” of the prepared statement syntax and will just do a STR."" format. Or they might consider the database.executeQuery."SELECT \{x}"; syntax “invalid” and try to fix it.

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

#79

Post by bberrry »

qw wrote: post #48
Noe2097 wrote: post #22

Why oh why is that a backslash!? Over the 9 languages mentioned: 5 languages (inc. JVM ones like groovy and kotlin) are using `$`, 1 language (swift) is using `\`. `\` is a pain to type on many keyboard layouts -- actually most but the US one. It seemed to me that `$` would have been a much more "conventional" choice. This really makes me sad. It looks like the choice was made on purpose to be different.

I agree. On my keyboard I need to press ⌥ + ⌘ + 7 It's actually made worse because { and } also need special combinations. To type \{X} I need to press (⌥ + ⌘ + 7) (SHIFT + ⌥ + 8) X (SHIFT + ⌥ + 9) I know this is something we need to live with due to historical reasons, but I would prefer that new syntax is made simpler.

Agreed, the economics for this syntax is terrible.

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

#80

Post by isbvhodnvemrwvn »

geodel wrote: post #16
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.

Sarcasm carries poorly over text :)
Post reply on HN