Now that Java 21 is features complete (Rampdown Phase Two at the day of writing), it’s time to walk through all the functionalities that bring to us, developers, this new version. This article is part of a series on what’s new on the last versions of Java, for those who wants to read the others,
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!
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.
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.
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.
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!
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.