Live data from Hacker News

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

openjdk.org

21–30 of 246 posts

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

#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 discover that almost no C developers actually understand what goes on with unsigned, what unsigned arithmetic is. Things like that made C complex. The language part of Java is, I think, pretty simple. The libraries you have to look up.[0]

So we can have this super powerful, extensible string interpolation system using never-before-seen syntax as a language feature, not a standard library extension, but not unsigned integers?

I'll echo what other commenters have said: This looks powerful but ugly. I'll add to it by pointing out that "powerful but ugly" is what we've already got. So we gain the ability to move format arguments inline with the string contents if we're willing to use the `STR."\{}"` syntax? That seems like a lateral move.

0. http://www.gotw.ca/publications/c_family_interview.htm

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

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

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

#23
It's interesting that this feature is essentially a clone of how string interpolation has been made extensible in Scala. However, the JEP only mentions Scala once.... in the form of an example which has been made strangely more complex than it has to be (it would be much shorter if they had used the s interpolator instead of the f interpolator).

The one major difference is that, because Scala has macros and typeclasses, it can turn malformed interpolations for things like JSON or SQL into compile-time errors instead of runtime errors.

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

#24
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'd also really have preferred $, but apparently there's some backwards compatibility issue with using that character?

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

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

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

#26

> 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, especially in server-side software, where Java is mostly used.

As to `STR.` -- which you won't need to use most of the time -- see my other comment: https://news.ycombinator.com/item?id=35013470

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

#27
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'm not a fan either. Java seems to be declining in prevalence in my corner of industry, I'm sure these changes are made by wiser minds than mine, but I'm sceptical about whether such a choice is really right for users.

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

#28
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 assume because `\{` was not a valid escape sequence, which means any use of this character pair can be identified as a template without changing the semantics of existing string literals.

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

#29
post #24
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'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.

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

#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.
Post reply on HN