Hacker News Reader

Comment by wiseowise | Hacker News Reader

There's literally two sections explaining why it is the way it is.

> String interpolation is dangerous > Can we do better?

But they've made the common case much worse.

For the 'injection' case, they could define an annotation which stops interpolation on a provided parameter, and provide a more verbose method to handle templated interpolation correctly.

A sample syntax by JetBrains is below. [0] In future, this could be leveraged to block/warn against dangerous interpolations

    @Language("SQL") // This adds SQL highlighting, encouraging developers to use it
    String query = "SELECT * FROM Person p WHERE p.last_name = '${name}'" // future warning/error

[0] https://www.jetbrains.com/help/idea/using-language-injection...

Yeah that's great for new code. What about all the old code people have written and they want to upgrade to the new version of the language? `\{` used to be invalid syntax for the string, so if they add meaning to that syntax then it won't break old code. There's a lot of extant code for Java.

"IDENTIFIER, PERIOD, LITERAL" is also invalid syntax before this JEP, and it's the only way to enable string templates. The processing of untagged string literals is not changed.

It's not better though. The STR template processor behaves the exact same way as all the other examples, and it's the one that all the inexperienced devs prone to this kind of injection attack will use.

The approach of defining template processors is definitely better. Moving from unsafe to safe is "just" switching STR to whatever secure processor team writes.

They won't use it if the APIs for generating HTML/JSON/SQL don't take String (or deprecate the old methods that do). The various APIs can support only their own, safe processors, and if an API doesn't take a String then you can't pass it interpolated strings.

Reply on news.ycombinator.com