5 ms·

We could have unsigned integers but we're choosing not to because on the whole their disadvantages outweigh their advantages. On the other hand, once we have us

by pron 4y ago

We could have unsigned integers but we're choosing not to because on the whole their disadvantages outweigh their advantages. On the other hand, once we have user-defined value types, you'll be able to define unsigned integers in a library if you want. The extensibility and power of string templates were a requirement; security experts quite simply vetoed adding string interpolation as it's just too dangerous, especially in server-side software, where Java is mostly used. As to `STR.` -- which you won't need to use most of the time -- see my other comment: https://news.ycombinator.com/item?id=35013470 https://news.ycombinator.com/item?id=35013470

Kwpolska 4y ago
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.
rcoveson 4y ago
> We could have unsigned integers but we're choosing not to because on the whole their disadvantages outweigh their advantages. You (collectively) have this wrong; C, C++, C#, Rust, Go, et al. have it right. As long as we're just stating our beliefs outright instead of justifying them, that is. (That's not a request to justify your opinion; I'm sure it's been argued to death already.) > security experts quite simply vetoed adding string interpolation as it's just too dangerous Laughable. In an alternate universe where it didn't already exist, this could have been a JEP for StringBuilder and they would have vetoed that too. > As to `STR.` -- which you won't need to use most of the time Except for when you're trying to... make a String? Which is what ~everybody who ever asked for string interpolation in Java wanted to do? What year would you estimate it will be when, at the average Java job, I can expect that most of the library APIs available to me which were often invoked with the form `func(String.format(...))` will have similar APIs that behave as JEP 430 template processors? Maybe after it's been full release for 3 years? 2, optimistically? Because during those years, in order to use this thing at all, people will be using `STR."\{}"`
- pron 4y ago
  Maybe you're right, but I think it's not so much a matter of what's right or wrong, but what's appropriate for languages with different audience size. Our experience is at evolving a language for a certain audience size, and perhaps if Java's popularity declines to the more modest market shares of the languages you mentioned, their choices may become appropriate for Java, too. As to your other points, like I explained to someone else here, even three decades of experience evolving a language that's achieved a measure of success is still no guarantee that every feature will work well, which is why most big new features, string templates included, are first released as preview (i.e. a feature that may change). That allows us to test our hypotheses against the problems people actually encounter rather than those we or others may speculate they'd encounter, and adjust the feature accordingly before it is finalised. To the best of my knowledge, all preview features have undergone some adjustment before becoming permanent, but usually the changes required were relatively small. Also, we try to think more long-term, because in ten years no one is going to care or even remember if a feature arrived five or seven years prior.
- 4y ago
chlorion 4y ago
> We could have unsigned integers but we're choosing not to because on the whole their disadvantages outweigh their advantages. On the other hand, once we have user-defined value types, you'll be able to define unsigned integers in a library if you want. What disadvantages do unsigned ints have?
- kaba0 4y ago
  https://news.ycombinator.com/item?id=35018974 https://news.ycombinator.com/item?id=35018974
- pron 4y ago
  Underflows are much more common than overflows (most numbers are small) and people again and again fall under the impression that unsigned integers are a good way to represent positive numbers, which is not at all what they do. E.g. C++ is very unhappy with the mistake they made of representing sizes with unsigned types [1]. Unsigned types are also primarily useful when the types have very few bits -- like in bitfields -- but Java doesn't have those, and the uses of unsigned types in Java would be mostly restricted to interaction with native code and hardware, that not many do and for which we have other solutions. So some very dangerous disadvantages and not many advantages for a language like Java. [1]: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1428r0.pdf https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p14...
  - gergo_barany 4y ago
    > E.g. C++ is very unhappy with the mistake they made of representing sizes with unsigned types [1]. 95% of that unhappiness seems to be due to mixed signed/unsigned expressions with implicit conversions. Java wouldn't be forced to repeat the mistake of making conversions implicit. The other 5% of the unhappiness is "machine integers are not mathematical integers". But that's the case for signed integers anyway. Overflowing your unsigned integer is almost certainly wrong, but overflowing your signed integer is almost certainly wrong as well. > not many advantages for a language like Java. Agreed.
    - 4y ago

by pron 4y ago

Kwpolska 4y ago

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.

rcoveson 4y ago

> We could have unsigned integers but we're choosing not to because on the whole their disadvantages outweigh their advantages. You (collectively) have this wrong; C, C++, C#, Rust, Go, et al. have it right. As long as we're just stating our beliefs outright instead of justifying them, that is. (That's not a request to justify your opinion; I'm sure it's been argued to death already.) > security experts quite simply vetoed adding string interpolation as it's just too dangerous Laughable. In an alternate universe where it didn't already exist, this could have been a JEP for StringBuilder and they would have vetoed that too. > As to `STR.` -- which you won't need to use most of the time Except for when you're trying to... make a String? Which is what ~everybody who ever asked for string interpolation in Java wanted to do? What year would you estimate it will be when, at the average Java job, I can expect that most of the library APIs available to me which were often invoked with the form `func(String.format(...))` will have similar APIs that behave as JEP 430 template processors? Maybe after it's been full release for 3 years? 2, optimistically? Because during those years, in order to use this thing at all, people will be using `STR."\{}"`

pron 4y ago
Maybe you're right, but I think it's not so much a matter of what's right or wrong, but what's appropriate for languages with different audience size. Our experience is at evolving a language for a certain audience size, and perhaps if Java's popularity declines to the more modest market shares of the languages you mentioned, their choices may become appropriate for Java, too. As to your other points, like I explained to someone else here, even three decades of experience evolving a language that's achieved a measure of success is still no guarantee that every feature will work well, which is why most big new features, string templates included, are first released as preview (i.e. a feature that may change). That allows us to test our hypotheses against the problems people actually encounter rather than those we or others may speculate they'd encounter, and adjust the feature accordingly before it is finalised. To the best of my knowledge, all preview features have undergone some adjustment before becoming permanent, but usually the changes required were relatively small. Also, we try to think more long-term, because in ten years no one is going to care or even remember if a feature arrived five or seven years prior.
4y ago

chlorion 4y ago

> We could have unsigned integers but we're choosing not to because on the whole their disadvantages outweigh their advantages. On the other hand, once we have user-defined value types, you'll be able to define unsigned integers in a library if you want. What disadvantages do unsigned ints have?

kaba0 4y ago
https://news.ycombinator.com/item?id=35018974 https://news.ycombinator.com/item?id=35018974
pron 4y ago
Underflows are much more common than overflows (most numbers are small) and people again and again fall under the impression that unsigned integers are a good way to represent positive numbers, which is not at all what they do. E.g. C++ is very unhappy with the mistake they made of representing sizes with unsigned types [1]. Unsigned types are also primarily useful when the types have very few bits -- like in bitfields -- but Java doesn't have those, and the uses of unsigned types in Java would be mostly restricted to interaction with native code and hardware, that not many do and for which we have other solutions. So some very dangerous disadvantages and not many advantages for a language like Java. [1]: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1428r0.pdf https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p14...
- gergo_barany 4y ago
  > E.g. C++ is very unhappy with the mistake they made of representing sizes with unsigned types [1]. 95% of that unhappiness seems to be due to mixed signed/unsigned expressions with implicit conversions. Java wouldn't be forced to repeat the mistake of making conversions implicit. The other 5% of the unhappiness is "machine integers are not mathematical integers". But that's the case for signed integers anyway. Overflowing your unsigned integer is almost certainly wrong, but overflowing your signed integer is almost certainly wrong as well. > not many advantages for a language like Java. Agreed.
  - 4y ago