3 ms·

There's literally two sections explaining why it is the way it is. > String interpolation is dangerous > Can we do better?

ticklemyelmo 3y ago
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.
- wiseowise 3y ago
  The approach of defining template processors is definitely better. Moving from unsafe to safe is "just" switching STR to whatever secure processor team writes.
- pron 3y ago
  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.
david_allison 3y ago
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-injections.html https://www.jetbrains.com/help/idea/using-language-injection...
- djha-skin 3y ago
  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.
  - masklinn 3y ago
    "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.

ticklemyelmo 3y ago

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.

wiseowise 3y ago
The approach of defining template processors is definitely better. Moving from unsafe to safe is "just" switching STR to whatever secure processor team writes.
pron 3y ago
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.

david_allison 3y ago

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-injections.html https://www.jetbrains.com/help/idea/using-language-injection...

djha-skin 3y ago
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.
- masklinn 3y ago
  "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.