7 ms·

Here's the reasoning why it turned out to be flawed and had to be scrapped, https://www.reddit.com/r/java/comments/1bxck72/comment/kz48ffv/ https://www.reddit.c

by AhtiK 2y ago

Here's the reasoning why it turned out to be flawed and had to be scrapped, https://www.reddit.com/r/java/comments/1bxck72/comment/kz48ffv/ https://www.reddit.com/r/java/comments/1bxck72/comment/kz48f... Brian Goetz is one of the Java language&JDK architects.

bradhe 2y ago
Maybe I'm dense but I learned nothing from this link. What was the actual flaw?
- marginalia_nu 2y ago
  I think he's referring to this discussion: https://mail.openjdk.org/pipermail/amber-spec-experts/2024-April/004106.html https://mail.openjdk.org/pipermail/amber-spec-experts/2024-A...
  - dang 2y ago
    Thanks! We've changed the top link to that from https://bugs.openjdk.org/browse/JDK-8329949 https://bugs.openjdk.org/browse/JDK-8329949, which is mostly just a pointer.
- mvonballmo 2y ago
  It's not just you. My reading is that the flaw was toxic Java users made the developers feel so bad about the feature that they canceled it out of spite. I'm almost certain that's not what it was but that's the only information in there.
  - vips7L 2y ago
    Yeah lots of bikeshedding over \ instead of $ was just really unnecessary.
- darylteo 2y ago
  This might be a better post. Brian's original email is here. https://mail.openjdk.org/pipermail/amber-spec-experts/2024-April/004106.html https://mail.openjdk.org/pipermail/amber-spec-experts/2024-A... > In the course of using this feature in the `jextract` project, we did learn quite a few things we didn’t already know, and this was conclusive enough that it has motivated us to adjust our approach in this feature. Specifically, the role of processors is “outsized” to the value they offer, and, after further exploration, we now believe it is possible to achieve the goals of the feature without an explicit “processor” abstraction at all! This is a very positive development. My Summary: - nothing to do with the choice of backslash vs dollar. Doubles down on dollar being bad (due to backward and cross compat with other languages) - original choice to use "Template Processors" misguided, reverses course to StringTemplate Literals - this requires a new paradigm where APIs now need to explicitly support StringTemplates, instead of relying on the Processor to convert them into Strings as necessary (big leap in my logic here) - StringTemplates are explicitly still not Strings. This is in line with their "Security Focus First" - sensitive APIs that depend on StringTemplates should explicitly treat their interpolated results carefully through overloads in a sensitive context. Obviously I don't know much about the `jextract` project but I can guess 1 possible way this breaks the security concept is if you use the wrong Processor to pass into a Db.query method, for example. db.query(STR."select * from users where id = \{id};"); This way, you can still do it, but its just much harder to do. Or as an API developer you could deprecate your String overload and insist only on StringTemplate usage from now on. db.query("select * from users where id = \{id};"); // this is compiled as a StringTemplate db.query("select * from users where id = \"" + id "\""); // this is still a String, and it's still bad, but can be mitigated by deprecating Stringm method Disclaimer: i haven't done java in nearly 10 years... i just love theorycrafting. So take my contribution with a pinch of salt please :)
  - MrJohz 2y ago
    That's actually a really clever mechanism. Although it'll make the common case (basic string interpolation, no need for security concerns) more complicated unless a lot of APIs support a StringTemplate overload.
    - 2y ago
pgwhalen 2y ago
This comment is *not* an explanation of why the feature was problematic in its current form, and portraying it that way makes the JDK team look far more political than they actually are. The comment is just explaining why feedback from usage is better than comments just looking at syntax. A sibling comment links to the actual technical discussion and reasoning.
- unlikelytomato 2y ago
  I understand where you are coming from, but it is a very good signal for the team. The easiest way to get the desired feedback would probably be to adequately address to the current community concern.
  - pgwhalen 2y ago
    It is very well addressed, in the right forum (on the OpenJDK mailing list). It's a bit uncharitable to cherry pick a reddit comment on a specific thing and portray that as the public messaging on the technical decision. I want Brian et al. to comment more on reddit threads, not less, but this sort of interpretation is a reason for him not to.
    - unlikelytomato 2y ago
      I'm not taking a particular stance on the JEP. I am not sure what is being cherry picked. The comment explicitly called out the customers for creating antihelpful noise. In my eyes, that tells me there is deep value misalignment between the involved parties, which is worth reflecting on.
- AhtiK 2y ago
  "We discovered, unfortunately quite late in the game, that the design was flawed."
  - favorited 2y ago
    That's an explanation of why the feature was pulled, not of why it was problematic in its current form.
mvdtnz 2y ago
That doesn't clear anything up.

by AhtiK 2y ago

bradhe 2y ago

Maybe I'm dense but I learned nothing from this link. What was the actual flaw?

marginalia_nu 2y ago
I think he's referring to this discussion: https://mail.openjdk.org/pipermail/amber-spec-experts/2024-April/004106.html https://mail.openjdk.org/pipermail/amber-spec-experts/2024-A...
- dang 2y ago
  Thanks! We've changed the top link to that from https://bugs.openjdk.org/browse/JDK-8329949 https://bugs.openjdk.org/browse/JDK-8329949, which is mostly just a pointer.
mvonballmo 2y ago
It's not just you. My reading is that the flaw was toxic Java users made the developers feel so bad about the feature that they canceled it out of spite. I'm almost certain that's not what it was but that's the only information in there.
- vips7L 2y ago
  Yeah lots of bikeshedding over \ instead of $ was just really unnecessary.
darylteo 2y ago
This might be a better post. Brian's original email is here. https://mail.openjdk.org/pipermail/amber-spec-experts/2024-April/004106.html https://mail.openjdk.org/pipermail/amber-spec-experts/2024-A... > In the course of using this feature in the `jextract` project, we did learn quite a few things we didn’t already know, and this was conclusive enough that it has motivated us to adjust our approach in this feature. Specifically, the role of processors is “outsized” to the value they offer, and, after further exploration, we now believe it is possible to achieve the goals of the feature without an explicit “processor” abstraction at all! This is a very positive development. My Summary: - nothing to do with the choice of backslash vs dollar. Doubles down on dollar being bad (due to backward and cross compat with other languages) - original choice to use "Template Processors" misguided, reverses course to StringTemplate Literals - this requires a new paradigm where APIs now need to explicitly support StringTemplates, instead of relying on the Processor to convert them into Strings as necessary (big leap in my logic here) - StringTemplates are explicitly still not Strings. This is in line with their "Security Focus First" - sensitive APIs that depend on StringTemplates should explicitly treat their interpolated results carefully through overloads in a sensitive context. Obviously I don't know much about the `jextract` project but I can guess 1 possible way this breaks the security concept is if you use the wrong Processor to pass into a Db.query method, for example. db.query(STR."select * from users where id = \{id};"); This way, you can still do it, but its just much harder to do. Or as an API developer you could deprecate your String overload and insist only on StringTemplate usage from now on. db.query("select * from users where id = \{id};"); // this is compiled as a StringTemplate db.query("select * from users where id = \"" + id "\""); // this is still a String, and it's still bad, but can be mitigated by deprecating Stringm method Disclaimer: i haven't done java in nearly 10 years... i just love theorycrafting. So take my contribution with a pinch of salt please :)
- MrJohz 2y ago
  That's actually a really clever mechanism. Although it'll make the common case (basic string interpolation, no need for security concerns) more complicated unless a lot of APIs support a StringTemplate overload.
  - 2y ago

pgwhalen 2y ago

This comment is *not* an explanation of why the feature was problematic in its current form, and portraying it that way makes the JDK team look far more political than they actually are. The comment is just explaining why feedback from usage is better than comments just looking at syntax. A sibling comment links to the actual technical discussion and reasoning.

unlikelytomato 2y ago
I understand where you are coming from, but it is a very good signal for the team. The easiest way to get the desired feedback would probably be to adequately address to the current community concern.
- pgwhalen 2y ago
  It is very well addressed, in the right forum (on the OpenJDK mailing list). It's a bit uncharitable to cherry pick a reddit comment on a specific thing and portray that as the public messaging on the technical decision. I want Brian et al. to comment more on reddit threads, not less, but this sort of interpretation is a reason for him not to.
  - unlikelytomato 2y ago
    I'm not taking a particular stance on the JEP. I am not sure what is being cherry picked. The comment explicitly called out the customers for creating antihelpful noise. In my eyes, that tells me there is deep value misalignment between the involved parties, which is worth reflecting on.
AhtiK 2y ago
"We discovered, unfortunately quite late in the game, that the design was flawed."
- favorited 2y ago
  That's an explanation of why the feature was pulled, not of why it was problematic in its current form.

mvdtnz 2y ago

That doesn't clear anything up.