4 ms·

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,

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?

pron 4y ago
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 languages is a fact reported by all security advisories. String interpolation is one of the most dangerous features a language can have.
- optician_owl 4y ago
  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).
- Kwpolska 4y ago
  I’m not a fan of the special `log.info."x: \{x}";` syntax, it looks like a weird mix of field access and a string literal. And even with the fancy new syntax, I’m sure there will be people passing STR."SELECT * FROM x WHERE y = \{y}" to their database. You can educate people all you want, but not all developers will read the docs telling them this is dangerous. Even if all the docs do the right thing, people might end up reading old tutorials, and will then notice the “inefficiency” of the prepared statement syntax and will just do a STR."" format. Or they might consider the database.executeQuery."SELECT \{x}"; syntax “invalid” and try to fix it.
  - pron 4y ago
    Well, you know, even thirty years of experience as the custodians of one of the most successful programming languages is no guarantee of success with every feature, but that's why we have the preview process now that lets us figure out what problems people actually encounter -- which may well be different from the problems they, or we, think they would encounter -- before finalising the feature. Just remember that you can't pass a string to an API that doesn't take strings, and even with existing APIs, methods that take strings can be deprecated to cause compiler warnings. So sometimes there are stronger ways than just documentation to discourage dangerous code.
    - avgcorrection 4y ago
      If I had a cent for every time pron appealed to Java’s age and “popularity” in technical arguments, I would have at least enough cents to use a dollar-sign in string template syntax.
      - pron 4y ago
        That's cute, but that appeal is crucial because technical arguments that are divorced from empirical results in the field are a great way to spend a lot of time solving the wrong problems. For example, you can make technical arguments in favour of either VHS or Betamax, but while they both had superior solutions to two separate technical problems, one of those problems (recording time) ended up being a much more important one for more people than the other. The purpose of engineering is not to enjoy intellectual puzzles, but to solve problems for people. You can only insist that the team that's at or near the top of the charts for so many years don't know what they're doing so many times. After a while, you may want to reconsider your beliefs about what the right approach is. Those who misunderstand that will forever be puzzled by why it is that the VHSes usually win over the Betamaxes, and will continue betting on the wrong horses. The relatively new concept of preview features helps us gather information on what problems people actually encounter when working with a new feature as opposed to what problems some speculate they'll run into. The best way to influence Java's direction is not to speculate, but to report problems you've actually encountered to the relevant OpenJDK mailing list (amber-dev in this case). If the use of the \ or $ character turns out to be a real problem, we expect to find that out during the preview process (which will begin in JDK 21, out this September) and we'll reconsider, only we'll do it based on reports, not speculation.
- zelphirkalt 4y ago
  When I want to write a query, I will use a prepared statement or read the docs of a library I am using to interact with a database, whether that library automatically creates a prepared statement. If I use a prepared statement and later read that code, I never again have to ask myself, whether it is safe. Quite frankly, who does not know about injection and prepared statements should not work with databases.
  - Kwpolska 4y ago
    Beginners tend to shoot themselves in the foot fairly often.
- yxhuvud 4y ago
  Isn't that better solved by not allowing templates to be passed around and blanks filled in later but instead force them to be executed immediately? This is the case in Ruby and while there have been plenty cases of code injection, I've never seen one using the basic string interpolation to do that.
  - pron 4y ago
    It's not a better solution but one part of this solution (which also requires templates to originate in the program rather than as input by requiring literals). The rest is done to ensure proper, context-specific quoting/escaping for machine-interpretable constructs, such as JSON and SQL. As to the dangers of simple string interpolation, here's a warning against using C#'s string interpolation in favour of a safer C# construct: https://bengribaudo.com/blog/2021/04/13/5596/intercepting-string-interpolation https://bengribaudo.com/blog/2021/04/13/5596/intercepting-st... We want to make the safe choice the easiest choice, and certainly not the trickier choice. We do that by adding a small tax to the dangerous choice -- i.e. string interpolation. When this feature previews we'll know more about how well this works and can then adjust based on people's actual experience.

pron 4y ago

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 languages is a fact reported by all security advisories. String interpolation is one of the most dangerous features a language can have.

optician_owl 4y ago
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).
Kwpolska 4y ago
I’m not a fan of the special `log.info."x: \{x}";` syntax, it looks like a weird mix of field access and a string literal. And even with the fancy new syntax, I’m sure there will be people passing STR."SELECT * FROM x WHERE y = \{y}" to their database. You can educate people all you want, but not all developers will read the docs telling them this is dangerous. Even if all the docs do the right thing, people might end up reading old tutorials, and will then notice the “inefficiency” of the prepared statement syntax and will just do a STR."" format. Or they might consider the database.executeQuery."SELECT \{x}"; syntax “invalid” and try to fix it.
- pron 4y ago
  Well, you know, even thirty years of experience as the custodians of one of the most successful programming languages is no guarantee of success with every feature, but that's why we have the preview process now that lets us figure out what problems people actually encounter -- which may well be different from the problems they, or we, think they would encounter -- before finalising the feature. Just remember that you can't pass a string to an API that doesn't take strings, and even with existing APIs, methods that take strings can be deprecated to cause compiler warnings. So sometimes there are stronger ways than just documentation to discourage dangerous code.
  - avgcorrection 4y ago
    If I had a cent for every time pron appealed to Java’s age and “popularity” in technical arguments, I would have at least enough cents to use a dollar-sign in string template syntax.
    - pron 4y ago
      That's cute, but that appeal is crucial because technical arguments that are divorced from empirical results in the field are a great way to spend a lot of time solving the wrong problems. For example, you can make technical arguments in favour of either VHS or Betamax, but while they both had superior solutions to two separate technical problems, one of those problems (recording time) ended up being a much more important one for more people than the other. The purpose of engineering is not to enjoy intellectual puzzles, but to solve problems for people. You can only insist that the team that's at or near the top of the charts for so many years don't know what they're doing so many times. After a while, you may want to reconsider your beliefs about what the right approach is. Those who misunderstand that will forever be puzzled by why it is that the VHSes usually win over the Betamaxes, and will continue betting on the wrong horses. The relatively new concept of preview features helps us gather information on what problems people actually encounter when working with a new feature as opposed to what problems some speculate they'll run into. The best way to influence Java's direction is not to speculate, but to report problems you've actually encountered to the relevant OpenJDK mailing list (amber-dev in this case). If the use of the \ or $ character turns out to be a real problem, we expect to find that out during the preview process (which will begin in JDK 21, out this September) and we'll reconsider, only we'll do it based on reports, not speculation.
zelphirkalt 4y ago
When I want to write a query, I will use a prepared statement or read the docs of a library I am using to interact with a database, whether that library automatically creates a prepared statement. If I use a prepared statement and later read that code, I never again have to ask myself, whether it is safe. Quite frankly, who does not know about injection and prepared statements should not work with databases.
- Kwpolska 4y ago
  Beginners tend to shoot themselves in the foot fairly often.
yxhuvud 4y ago
Isn't that better solved by not allowing templates to be passed around and blanks filled in later but instead force them to be executed immediately? This is the case in Ruby and while there have been plenty cases of code injection, I've never seen one using the basic string interpolation to do that.
- pron 4y ago
  It's not a better solution but one part of this solution (which also requires templates to originate in the program rather than as input by requiring literals). The rest is done to ensure proper, context-specific quoting/escaping for machine-interpretable constructs, such as JSON and SQL. As to the dangers of simple string interpolation, here's a warning against using C#'s string interpolation in favour of a safer C# construct: https://bengribaudo.com/blog/2021/04/13/5596/intercepting-string-interpolation https://bengribaudo.com/blog/2021/04/13/5596/intercepting-st... We want to make the safe choice the easiest choice, and certainly not the trickier choice. We do that by adding a small tax to the dangerous choice -- i.e. string interpolation. When this feature previews we'll know more about how well this works and can then adjust based on people's actual experience.