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

41–50 of 246 posts

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

#41

Post by spankalee »

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 safe DSL embeddings.

(I don't love the syntax, but... it's Java)

edit: the other critical feature of JS tagged template literals, that I'm not sure this has, is referential equality of the template strings passed to the tag function across multiple invocations.

This is required to be able to do one-time preparation work on a template and re-use that with different sets of values. Think a `SQL.` template processor that turns the strings into a prepared statement once and re-uses that for each query with different parameters.

edit 2: awesome, it does:

    The fragments() of a StringTemplate are constant across all evaluations of a template expression, while values() is computed fresh for each evaluation. For example:

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

#42

Post by ko27 »

It's interesting how C# is always far ahead of Java, they introduced it way earlier, the syntax is simpler, and you can make is safe by using FormattableString as the param type, for example in EF you can do this without worrying about SQL injection:

FromSql($"EXECUTE dbo.GetMostPopularBlogsForUser {user}")

https://learn.microsoft.com/en-us/ef/core/querying/sql-queri...

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

#43

Post by SyrupThinker »

pdevr wrote: post #39
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.

Seriously, yes. Great thought process behind the design, marred by the good-for-nothing (subjective opinion) backslash. If any of you design a language or a DSL, please, please - avoid the backslash - for the reasons stated above. Hard to type, introduces unseen problems, most will hate it. It (backslash) is unbecoming, of anything elegant.

But if you do follow that advice consider if it is worth just using a different escape character for all interpolations. That way could still make use of this very sensible syntax of reusing the escape for interpolation whilst avoiding the backslash issues.

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

#44

Post by spankalee »

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 don't understand this rationale either:

> For the syntax of embedded expressions we considered using ${...}, but that would require a tag on string templates (either a prefix or a delimiter other than ") to avoid conflicts with legacy code.

Can't the template processor expression itself function as the tag? Is STR."..." already legal now?

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

#45

Post by pron »

_old_dude_ wrote: post #25

It seems the design team has lost its mojo. First, the lesson of Log4Shell have not been learnt. Allowing more libraries to do formatting, what can go wrong ? And String.format() is slow because every values are boxed. This JEP repeats the same mistake with the templates.

The template instantiation itself is done by the language, not libraries, and the entire mechanism was designed for security (read the JEP); for example, templates are (virtually) limited to literals and can't come from user input.

As to boxing, the built-in template processors, STR and FMT, don't do boxing (they use MethodHandle mechanisms similar to those used by lambdas) -- FMT is ~40x faster than String.format, I'm told -- but that capability hasn't been exposed as an API yet. As with other features, we try exposing basic usages first, and more sophisticated ones later.

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

#46

Post by Kwpolska »

pron wrote: post #26
rcoveson wrote: post #21

> Gosling: For me as a language designer, which I don't really count myself as these days, what "simple" really ended up meaning was could I expect J. Random Developer to hold the spec in his head. That definition says that, for instance, Java isn't -- and in fact a lot of these languages end up with a lot of corner cases, things that nobody really understands. Quiz any C developer about unsigned, and pretty soon you…

We could have unsigned integers but we're choosing not to because on the whole their disadvantages outweigh their advantages. On the other hand, once we have user-defined value types, you'll be able to define unsigned integers in a library if you want. The extensibility and power of string templates were a requirement; security experts quite simply vetoed adding string interpolation as it's just too dangerous, especi…

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?

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

#47

Post by AtlasBarfed »

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.

If anything Java is becoming groovy. Almost all features adopted are groovy features.

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

#48

Post by qw »

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.

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

#49

Post by oblio »

pron wrote: post #13
jsiepkes wrote: post #7

Earlier quoted context omitted.

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", lan…

Yeah, you're mostly right, but then... generics.

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

#50

Post by oblio »

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.

Is Scala rising? It used to be hyped a ton back in the earlier Twitter days, about 10 years ago, but since then, everything has been quiet.

If anything, Kotlin is probably ahead of Scala now, adoption wise.

Post reply on HN