Live data from Hacker News

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

openjdk.org

31–40 of 246 posts

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

#31
I thought the choice of STR was ugly at first but as you continue reading and see how that allows multiple options that provide more than generic string joining it really starts to make sense.

Unlike many here I do like the choice of \{}, although personally I would have preferred \() like Swift.

I can’t wait.

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

#32
post #29
post #24

Earlier quoted context omitted.

I'd also really have preferred $, but apparently there's some backwards compatibility issue with using that character?

“${val}” is a legal string literal that is certainly used in plenty of existing programs. In current Java you would have to escape \, so only “\\{val}” could have existed before.

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.

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

#33
post #13
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…

And honestly, in my opinion, that approach is just really proving itself right now. I am so happy to see Java seemingly on the right path again, adopting solid capabilities, innovating, but letting other languages take some punches first. We have had some dark days (maybe a dark decade), but full steam ahead now. Thank you pron and team!

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

#34
post #30

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

Then your STR would be used, and if you want to use this string template STR you would have to use it’s qualified name.

Or have an alias:

   public static final ValidationProcessor $ = ….STR;

   $.“My name is \{name}“

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

#37
post #11
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 h…

> So STR would only be used -- hopefully rarely

If that's the hope, why have it automatically imported statically for all files?

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

#38
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…

> 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?

Indeed. Please no more log4shell hell

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

#39
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.

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

#40
post #13
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…

Do you have a link for the 1997 document? The history is surprisingly difficult to explore for being pretty recent.
Post reply on HN