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

121–130 of 246 posts

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

#121

Post by vips7L »

layer8 wrote: post #113
vips7L wrote: post #94

Earlier quoted context omitted.

Supplier

That would require explicit support by each template processor implementation. The Object#toString approach works independently of the template processor (assuming they all call toString() on the parameters). Since the string template interface is untyped (parameters are arbitrary Objects), having case distinctions based on the type parameter is fiddly. What if you pass an instance of a class that has a genuine toStr…

I think you're thinking about it too much.

   log.info(() -> STR."template \{here}");

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

#122

Post by jayd16 »

pie_flavor wrote: post #114
ko27 wrote: post #42

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

You-the- user can make C#'s safe, you-the- library-developer can make Java's safe. All you need is for one silly person to assign the C# query to a `var` beforehand and then the behavior's wrong. I'd usually be the first to point out how C# did it earlier and better, but in this case Java's manages to surpass even Rust's, which I didn't think was possible.

Can you not make an analyzer that raises an error if you try to pass anything but a literal-as-format string?

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

#123

Post by sjrd »

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…

Scala has had all of that for years. This JEP literally copies the design of Scala string interpolators. Except that Scala has macros so, if desired, a string interpolator can perform validation at compile time, making it even more secure than what is being proposed here.

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

#124

Post by optician_owl »

ndriscoll wrote: post #19
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.

One of the best application I've seen is structured and contextual logging [1]. Combined with implicits, this allows you to require a right renderer or/and automatically get a current state of an execution context.

1. https://docs.tofu.tf/docs/tofu.logging.key-features/

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

#125

Post by optician_owl »

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 would argue that jdbc API is far more dangerous than string interpolation :)

But I wholeheartedly support the idea of JEP. Scala got several good UX benefits based on the string interpolation (sql and logging).

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

#126

Post by nunobrito »

cs02rm0 wrote: post #27
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'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.

I remain to be convinced and program daily in Java for a long time.

It seems just as difficult to remember/useless as lambda expressions that look fine as vanity one-line expressions and then get difficult to write for most programmers.

We don't really need vanity innovation in the Java world. I would have asked for priority on the FX replacement to Swing, or support for running on ESP32 IoT devices as replacement to the Arduino platform.

Instead we get some weird looking syntax for what is basically a non-problem.

¯\_(ツ)_/¯

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

#127

Post by kaba0 »

zelphirkalt wrote: post #97
taftster wrote: post #33

Earlier quoted context omitted.

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!

It is not really innovating, if it has been battle-tested by other languages, is it? While modern Java sometimes makes me think about reviving and modernizing an old project of mine, if Java is simply always behind by design of its evolution process, that makes it less likely, that I want to spend time with it.

Your mileage may vary, but I went from liking simple languages like Java, to very expressive, complex ones (Scala, Haskell, Rust) back to Java.

I mean, I like all those languages (and many more), but the thing is, most programs really don’t need all that many language features — an okayish type system, OOP for encapsulating private vs public state, and preferring immutable public APIs have served me well in almost every problem thrown at me.

I would much rather take a “boring” language with an absolutely huge ecosystem and just get my work done. Especially that after going high-level/managed, there is no feature that would give any significant productivity boost (as per Brooks).

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

#128

Post by kaba0 »

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.

Slightly unrelated, but I only buy ISO keyboards and have my native tongue layout (Hungarian) and English easily switched. The former absolutely sucked for any programming work, so I think we just sort of have to accept that programming is done with an en-us layout, the same way that (hopefully) all identifiers/comments are also in English.

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

#129

Post by optician_owl »

pron wrote: post #11
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 h…

As far as I understand the backslash is a mark of a variable. The problem that it looks like the escape symbol and this is really confusing. What about another symbol? #,%,|,Of course, $ is ideal because it's already everywhere and familiar.

I guess a typographer of a font designer would be helpful to find a good solution.

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

#130

Post by kaba0 »

nunobrito wrote: post #126
cs02rm0 wrote: post #27

Earlier quoted context omitted.

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.

I remain to be convinced and program daily in Java for a long time. It seems just as difficult to remember/useless as lambda expressions that look fine as vanity one-line expressions and then get difficult to write for most programmers. We don't really need vanity innovation in the Java world. I would have asked for priority on the FX replacement to Swing, or support for running on ESP32 IoT devices as replacement to…

> We don't really need vanity innovation in the Java world. I would have asked for priority on the FX replacement to Swing, or support for running on ESP32 IoT devices as replacement to the Arduino platform.

Which are entirely unrelated projects to this one with very different engineers working on it. Those are easily parallelized, if you will. I don’t see why having progress completely elsewhere by different people is detrimental to these goals at all.

Post reply on HN