this post was submitted on 10 Aug 2023
32 points (92.1% liked)

Programming

17352 readers
346 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Rules

  • Follow the programming.dev instance rules
  • Keep content related to programming in some way
  • If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities [email protected]



founded 1 year ago
MODERATORS
top 4 comments
sorted by: hot top controversial new old
[–] [email protected] 6 points 1 year ago* (last edited 1 year ago) (1 children)

It's great to see they're putting some effort into some really powerful string templates. I like the versitility in the approach they've gone with. Just a couple things stood out to me.

The problem with interpolation is that it’s dangerous as a global feature, because it doesn’t allow for validation or sanitization when constructing the final string. This exposes it, for example, to SQL or JavaScript injections.

Actually no, not having interpolation just makes it more verbose to create those vulnerabilities. Also, SQL injections aren't solved by validation and sanitization (well I guess in theory they can be if you're aggressive enough), they're solved with parameterized queries. These issues exist regardless, but lack of interpolation makes things significantly more verbose for the 99.9% of other cases where you aren't sending commands to a server. The cause of these vulnerabilities is inexperienced (or sometimes careless) developers trying to concat all their queries together, and this will help mitigate that but is unlikely to solve it.

The problem with interpolation seems to me to be a purely cultural thing. Pointing fingers at arbitrary reasons isn't really helping the argument against it, and it's completely valid to say "it just didn't feel like it belonged in Java until now, and we wanted to make sure we got it right", which I would much more readily believe.

There has been a lot of discussion around the choice of the expression format. Due to the existence of many libraries using $, # or {} as expression delimiters, the choice was for a format that is not valid outside String Templates

This seems backwards to me. Wouldn't you want them to feel as familiar as possible to users of these libraries and make migration easy for many users? It's not like the syntax for string templates would compile before anyway (unless there's something I'm missing) since they all require the template processor to be specified.

Skimming through the rest of the features, it seems like there's a lot of usability improvements, which is awesome to see!

[–] [email protected] 2 points 1 year ago

They all require the template processor to be specified, but I'm likely to convert hundreds or thousands of lines of existing string concatenation to templates in one of my projects and I really appreciate that the only \{ that show up will be the ones I create.

[–] [email protected] 3 points 1 year ago (1 children)

These changes are quite nice! Especially unnamed classes may help Java with it‘s verbosity issues…

[–] [email protected] 3 points 1 year ago

It will only help the earliest of beginners. If java 1.1 included this i would understand, but at this point I don't see it