9 ms·

Java string interpolation feature has been cancelled

71 points by neonsunset 2y ago

fabiofzero 2y ago
[flagged]
coldtea 2y ago
Not getting in JDK 23 release as a "preview future" (as was previously expected), because the design is not finalized yet, and the "preview" thing is to test drive mature designs ready to be in the language. It's not cancelled, and it's not even like the Go Generics situation, where the feature was shot down again and again due to endless deflection and bikeshedding. It will most likely make it in next round, which isn't that far in the future.
- jeffrallen 2y ago
  You know Go has generics right? They took the time to get them right, but then they did.
  - coldtea 2y ago
    Yes, hence me using the past tense ("was shot down again and again"). >They took the time to get them right, but then they did I'd say thet just took the time to bikeshed, and ended up not with the "right solution", but with a Not-Invented-Here remake of the Generics wheel with bizarre warts.
kernal 2y ago
brian_goetz: >Perhaps I can shed some light on this apparent contradiction. >We discovered, unfortunately quite late in the game, that the design was flawed. How was this discovered? By actually using it in a substantial, real-world internal project. But these flaws had little to do with "someone didn't like the syntax"; they were much more fundamental to the model. >Unfortunately, most of the feedback we received on public channels was of the "someone didn't like the syntax" variety (at varying levels of constructiveness, not all with positive coefficients). It did not derive from actual experience or from deep analysis; the supporting arguments provided were emotional, not technical; and it merely re-trod, with little new perspective, already-explored ground. It was literally a thousand drive-by, "blink" responses. >The net effect of this was not only unhelpful, but anti-helpful. I get that every developer has opinions about syntax, and seemingly some fraction of them will literally explode if they don't express it out loud, but such discussions are like an invasive species: they suck up the oxygen that is required for actually useful feedback to survive. (Or maybe the useful feedback was buried in there, but just got lost in all the noise.) >So the answer to your implied question is that its possible to be both: the feature can be discovered to be flawed, while at the same time the publicly available complaints were "nothing", as you say. It is sad, but possible.
deleted 2y ago
[deleted]
TrianguloY 2y ago
I like the direction of just having the templates being a separate object that you can use as parameters to another method, it removes that extra syntax that was more python-oriented than java. What I still don't like is the, apparently, automatic conversion of strings to templates? It's confusing because it's not clear in the new code how a template is identified. Just because it contains the \() part? But isn't one of the jep goals to allow apis to "allow Java libraries to define the formatting syntax used in string templates"? What if they used the backtick as a way to define a template? So that "abc \(f)" is a string but `abc \(f)` is a template? This will force developers to explicitly choose which one to use, but since automatic conversion is rejected, I think this is what makes more sense (plus libraries can decide with overloading to admit one, the other, or both).
rurban 2y ago
Not canceled! Just postponed. Pleased fix the headline
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 :)
geraldwhen 2y ago
It’s just an unsolved problem in computer science.
- superb_dev 2y ago
  String templates?
- bjoli 2y ago
  It is a source of so many security issues. Retracting a JEP that does not have broad support is the sane thing to do. There are enough languages with features that have not had every kink solved before standardisation. It is always a source of pain.
  - jbverschoor 2y ago
    How does it differ from just concatenating?
    - kaba0 2y ago
      You don’t want to just concatenate Little Bobby tables.
    - bjoli 2y ago
      Both are sources of vulnerabilities, of course. But I believe a nice string interpolation implementation can allow for validation (like the java one did). That means that whenever you are working with texts, a library can enforce constraints that in the case of concatenation would have meant a domain specific API for each library. My message isn't pick one over the other it is that whatever you pick, make sure it isn't a hack that people will regret using.
      - neonsunset 2y ago
        Definitely possible: https://learn.microsoft.com/en-us/ef/core/querying/sql-queries#composing-with-linq https://learn.microsoft.com/en-us/ef/core/querying/sql-queri...
beeboobaa3 2y ago
> The site is currently under maintenance. Please come back again later. What's this about?
- PedroBatista 2y ago
  They are compiling the JSPs. Wait a bit.
  - alserio 2y ago
    Compiling and executing jsp is still one of the most efficient way to template a web page. Although, not the most safe by default.
    - PedroBatista 2y ago
      I know, I was joking. I however have some PSTD from University times..
    - smallerfish 2y ago
      kotlinx.html is where it's at. Generally clean (though a few rough edges.)
      - alserio 2y ago
        I'm more for the approach used by JTE
        smallerfish 2y ago
        The @ directives are ugly - also the beauty of kotlinx.html is it's just code, so you get everything that the IDE provides for free. You shouldn't need a different type of file for this.
- sshine 2y ago
  If I were them, I'd interpolate that message a bit. But cancelling that ability seems to be what the fuss is about.
neonsunset 2y ago
mirror: https://web.archive.org/web/20240618081036/https://bugs.openjdk.org/browse/JDK-8329949 https://web.archive.org/web/20240618081036/https://bugs.open...
PedroBatista 2y ago
I've been following the JEPs from a distance and my feeling was that there wasn't really a "wow!" or great solution and a lot of mild disagreements. Maybe it's a bikeshedding situation, but since we are talking about language design and one with a huge instaled base I think this was the best decision since the upside is really not that great compared to the downside.
- deleted 2y ago
  [deleted]
- neonsunset 2y ago
  This is a well solved problem in languages like JS[0] and C#[1] allowing both plain and customized interpolation. Perhaps they wanted a different implementation and could not just take after prior art due to politics or culture? [0]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Template_literals#tagged_templates https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... [1]: https://learn.microsoft.com/en-us/ef/core/querying/sql-queries#passing-parameters https://learn.microsoft.com/en-us/ef/core/querying/sql-queri... (example showcases it better than API spec, C# generally lets you take it further to perform zero-allocation interpolation with custom interpolated handlers if you e.g. want to pass interpolated output into a buffer/stream/etc.)
david_allison 2y ago
https://news.ycombinator.com/item?id=38964824 https://news.ycombinator.com/item?id=38964824 [JEP draft: String Templates (Final)] - 5 months ago ---- I'll stand by my past point that it was unnecessarily verbose. I'm really glad they're going back to the drawing board with it
klauserc 2y ago
[flagged]
- deleted 2y ago
  [deleted]
- agilob 2y ago
  >That's just such a Java thing to do. "Oh we failed to design the perfect solution, so we are not going to change anything until we find that perfect solution." That's not true at all. In the last years there were lots of features that were introduced, later disabled, enabled and then disabled again because they were causing smaller or bigger issues. There was a major work on metaspace tuning (guard allocations) that went in, stayed in for 2 or 3 versions then was removed. AVX features were enabled and disabled multiple time because companies where getting wrong results or crashes. It's a fair game to remove something you as a developer don't consider ready. Just think how much garbage your team or company have shipped that wasn't ready, you had to patch under pressure or explain to users that it's not really working as described by marketing team and users should stick to old ways for a few more months.
  - klauserc 2y ago
    Totally agree about the "removing a misbehaving" feature part. The frustration I was trying to express is more related to "perfect being the enemy of good". JEP-430 was introduced 3 years ago. By that point C# has already had string interpolation in place for 6 years and the C# solution achieves 90% of what JEP-430 set out to do. Java users could have benefited from 90% of that feature for 9 years by now. It sounds a bit dramatic when we are talking about string interpolation, I realize that.
  - neonsunset 2y ago
    > AVX features There is also a proof that they can be shipped for a complex runtime without such level of pain: added back in .NET Core 3.0[0] and there were relatively few AVX-related bugs in the compiler since then and all of them were fixed in servicing (patch) releases upon discovery, without deprecation. [0]: https://learn.microsoft.com/en-us/dotnet/api/system.runtime.intrinsics.x86.avx2 https://learn.microsoft.com/en-us/dotnet/api/system.runtime....
nikanj 2y ago
Many of the proposed syntaxes for this feature were absolutely bonkers, nearly as bad as the ones proposed for raw strings. The JVM is technically impressive, but the syntax is almost C++ levels of terrible
- cryptos 2y ago
  Luckily there is Kotlin that gives programmers a nicer interface to the JVM.
  - soco 2y ago
    I have yet to see the real-world project where a nicer interface to the JVM makes the difference. Not saying that they don't exist, just that they are way less than one would assume.
  - pjmlp 2y ago
    While not taking advantage of all its features, because Android/ART.
  - valenterry 2y ago
    Yep. Just like Clojure, Scala and others, depending on the flavor. Just language-wise there is little reason for Java. But tooling and ecosystem are of course also relevant.
bob1029 2y ago
I can't imagine not having this. All of the web development I do today relies heavily on server-side string interpolation (and verbatim) features. Being able to do things like evaluate functions and iterate collections inline with HTML templates has allowed me to sidestep a lot of pain over the years.
- vips7L 2y ago
  > Being able to do things like evaluate functions and iterate collections inline with HTML templates has allowed me to sidestep a lot of pain over the years. Every single templating engine supports this. It doesn't need to be built into the core language. Here's an example from JTE [0]: @import org.example.Page @param Page page <head> @if(page.getDescription() != null) <meta name="description" content="${page.getDescription()}"> @endif <title>${page.getTitle()}</title> </head> <body> <h1>${page.getTitle()}</h1> <p>Welcome to my example page!</p> </body> [0] https://jte.gg/#__tabbed_2_1 https://jte.gg/#__tabbed_2_1
  - deleted 2y ago
    [deleted]
doikor 2y ago
It's strange as they point out that doing what Scala does is not possible as the language already has string literals that could contain the $ syntax stuff. But Scala does not enable string interpolation without explicitly using it by adding s infront of the string (s"some $value ${another}way") Though as they point out the syntax was not really the problem.
aster0id 2y ago
Why would anyone use java over kotlin for new projects? At least for server side development, kotlin has proved to be far superior to us.
- bradboimler 2y ago
  I find modern Java an absolute joy to program in. Kotlin doesn't solve any major problems I have with Java.
- rmrfchik 2y ago
  Because Kotlin as a mess language and have poor IDE support. $ kotlin Welcome to Kotlin version 1.6.10 (JRE 21.0.1+12-Debian-2) Type :help for help, :quit for quit >>> val b=ByteArray(1); >>> b[0] == 0; error: operator '==' cannot be applied to 'Byte' and 'Int' b[0] == 0; ^ $ jshell | Welcome to JShell -- Version 21.0.1 | For an introduction type: /help intro jshell> byte[] ba={0} ba ==> byte[1] { 0 } jshell> ba[0]==0 $2 ==> true upd: format
- simon_void 2y ago
  I prefer Kotlin over Java as well. I use it at work (where Java code has a tendency to become Kotlin code if it comes close to me) and at home. I'm looking forward to seeing how the native and wasm backends might extends the reach of Kotlin in the future.
- DarkNova6 2y ago
  Because syntax is the boring part of programming.
  - Mesopropithecus 2y ago
    I agree with that, but null safety would be a big deal for correctness.
  - favorited 2y ago
    Manually writing getters and setters is also pretty boring, in my experience.
DarkNova6 2y ago
Misleading Title. Actual title is: "Remove the String Templates preview feature" The feature is very much still in development. However, it's PREVIEW has been postponed.
hajimuz 2y ago
It’s under maintenance now. Kind of ironic.
ecopoesis 2y ago
This was always going to fail because the requirements were insane: solving SQL, XML and JSON generation should have never been part of the spec. There are hundreds, if not thousands of libraries for the those cases. The developers should have never tried to boil the ocean: simple Kotlin or Scala style interpolation with overloading `+` for concatenation is the 80% use case here. Yes it doesn’t do everything. But it makes life a lot more ergonomic. And they rejected this solution out of hand! So instead of something useful but not perfect we get nothing.

71 points by neonsunset 2y ago

[flagged]

Not getting in JDK 23 release as a "preview future" (as was previously expected), because the design is not finalized yet, and the "preview" thing is to test drive mature designs ready to be in the language. It's not cancelled, and it's not even like the Go Generics situation, where the feature was shot down again and again due to endless deflection and bikeshedding. It will most likely make it in next round, which isn't that far in the future.

jeffrallen 2y ago
You know Go has generics right? They took the time to get them right, but then they did.
- coldtea 2y ago
  Yes, hence me using the past tense ("was shot down again and again"). >They took the time to get them right, but then they did I'd say thet just took the time to bikeshed, and ended up not with the "right solution", but with a Not-Invented-Here remake of the Generics wheel with bizarre warts.

kernal 2y ago

brian_goetz: >Perhaps I can shed some light on this apparent contradiction. >We discovered, unfortunately quite late in the game, that the design was flawed. How was this discovered? By actually using it in a substantial, real-world internal project. But these flaws had little to do with "someone didn't like the syntax"; they were much more fundamental to the model. >Unfortunately, most of the feedback we received on public channels was of the "someone didn't like the syntax" variety (at varying levels of constructiveness, not all with positive coefficients). It did not derive from actual experience or from deep analysis; the supporting arguments provided were emotional, not technical; and it merely re-trod, with little new perspective, already-explored ground. It was literally a thousand drive-by, "blink" responses. >The net effect of this was not only unhelpful, but anti-helpful. I get that every developer has opinions about syntax, and seemingly some fraction of them will literally explode if they don't express it out loud, but such discussions are like an invasive species: they suck up the oxygen that is required for actually useful feedback to survive. (Or maybe the useful feedback was buried in there, but just got lost in all the noise.) >So the answer to your implied question is that its possible to be both: the feature can be discovered to be flawed, while at the same time the publicly available complaints were "nothing", as you say. It is sad, but possible.

deleted 2y ago

[deleted]

TrianguloY 2y ago

I like the direction of just having the templates being a separate object that you can use as parameters to another method, it removes that extra syntax that was more python-oriented than java. What I still don't like is the, apparently, automatic conversion of strings to templates? It's confusing because it's not clear in the new code how a template is identified. Just because it contains the \() part? But isn't one of the jep goals to allow apis to "allow Java libraries to define the formatting syntax used in string templates"? What if they used the backtick as a way to define a template? So that "abc \(f)" is a string but `abc \(f)` is a template? This will force developers to explicitly choose which one to use, but since automatic conversion is rejected, I think this is what makes more sense (plus libraries can decide with overloading to admit one, the other, or both).

rurban 2y ago

Not canceled! Just postponed. Pleased fix the headline

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 :)

geraldwhen 2y ago

It’s just an unsolved problem in computer science.

superb_dev 2y ago
String templates?
bjoli 2y ago
It is a source of so many security issues. Retracting a JEP that does not have broad support is the sane thing to do. There are enough languages with features that have not had every kink solved before standardisation. It is always a source of pain.
- jbverschoor 2y ago
  How does it differ from just concatenating?
  - kaba0 2y ago
    You don’t want to just concatenate Little Bobby tables.
  - bjoli 2y ago
    Both are sources of vulnerabilities, of course. But I believe a nice string interpolation implementation can allow for validation (like the java one did). That means that whenever you are working with texts, a library can enforce constraints that in the case of concatenation would have meant a domain specific API for each library. My message isn't pick one over the other it is that whatever you pick, make sure it isn't a hack that people will regret using.
    - neonsunset 2y ago
      Definitely possible: https://learn.microsoft.com/en-us/ef/core/querying/sql-queries#composing-with-linq https://learn.microsoft.com/en-us/ef/core/querying/sql-queri...

beeboobaa3 2y ago

> The site is currently under maintenance. Please come back again later. What's this about?

PedroBatista 2y ago
They are compiling the JSPs. Wait a bit.
- alserio 2y ago
  Compiling and executing jsp is still one of the most efficient way to template a web page. Although, not the most safe by default.
  - PedroBatista 2y ago
    I know, I was joking. I however have some PSTD from University times..
  - smallerfish 2y ago
    kotlinx.html is where it's at. Generally clean (though a few rough edges.)
    - alserio 2y ago
      I'm more for the approach used by JTE
      - smallerfish 2y ago
        The @ directives are ugly - also the beauty of kotlinx.html is it's just code, so you get everything that the IDE provides for free. You shouldn't need a different type of file for this.
sshine 2y ago
If I were them, I'd interpolate that message a bit. But cancelling that ability seems to be what the fuss is about.

neonsunset 2y ago

mirror: https://web.archive.org/web/20240618081036/https://bugs.openjdk.org/browse/JDK-8329949 https://web.archive.org/web/20240618081036/https://bugs.open...

PedroBatista 2y ago

I've been following the JEPs from a distance and my feeling was that there wasn't really a "wow!" or great solution and a lot of mild disagreements. Maybe it's a bikeshedding situation, but since we are talking about language design and one with a huge instaled base I think this was the best decision since the upside is really not that great compared to the downside.

deleted 2y ago
[deleted]
neonsunset 2y ago
This is a well solved problem in languages like JS[0] and C#[1] allowing both plain and customized interpolation. Perhaps they wanted a different implementation and could not just take after prior art due to politics or culture? [0]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Template_literals#tagged_templates https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... [1]: https://learn.microsoft.com/en-us/ef/core/querying/sql-queries#passing-parameters https://learn.microsoft.com/en-us/ef/core/querying/sql-queri... (example showcases it better than API spec, C# generally lets you take it further to perform zero-allocation interpolation with custom interpolated handlers if you e.g. want to pass interpolated output into a buffer/stream/etc.)

david_allison 2y ago

https://news.ycombinator.com/item?id=38964824 https://news.ycombinator.com/item?id=38964824 [JEP draft: String Templates (Final)] - 5 months ago ---- I'll stand by my past point that it was unnecessarily verbose. I'm really glad they're going back to the drawing board with it

klauserc 2y ago

[flagged]

deleted 2y ago
[deleted]
agilob 2y ago
>That's just such a Java thing to do. "Oh we failed to design the perfect solution, so we are not going to change anything until we find that perfect solution." That's not true at all. In the last years there were lots of features that were introduced, later disabled, enabled and then disabled again because they were causing smaller or bigger issues. There was a major work on metaspace tuning (guard allocations) that went in, stayed in for 2 or 3 versions then was removed. AVX features were enabled and disabled multiple time because companies where getting wrong results or crashes. It's a fair game to remove something you as a developer don't consider ready. Just think how much garbage your team or company have shipped that wasn't ready, you had to patch under pressure or explain to users that it's not really working as described by marketing team and users should stick to old ways for a few more months.
- klauserc 2y ago
  Totally agree about the "removing a misbehaving" feature part. The frustration I was trying to express is more related to "perfect being the enemy of good". JEP-430 was introduced 3 years ago. By that point C# has already had string interpolation in place for 6 years and the C# solution achieves 90% of what JEP-430 set out to do. Java users could have benefited from 90% of that feature for 9 years by now. It sounds a bit dramatic when we are talking about string interpolation, I realize that.
- neonsunset 2y ago
  > AVX features There is also a proof that they can be shipped for a complex runtime without such level of pain: added back in .NET Core 3.0[0] and there were relatively few AVX-related bugs in the compiler since then and all of them were fixed in servicing (patch) releases upon discovery, without deprecation. [0]: https://learn.microsoft.com/en-us/dotnet/api/system.runtime.intrinsics.x86.avx2 https://learn.microsoft.com/en-us/dotnet/api/system.runtime....

nikanj 2y ago

Many of the proposed syntaxes for this feature were absolutely bonkers, nearly as bad as the ones proposed for raw strings. The JVM is technically impressive, but the syntax is almost C++ levels of terrible

cryptos 2y ago
Luckily there is Kotlin that gives programmers a nicer interface to the JVM.
- soco 2y ago
  I have yet to see the real-world project where a nicer interface to the JVM makes the difference. Not saying that they don't exist, just that they are way less than one would assume.
- pjmlp 2y ago
  While not taking advantage of all its features, because Android/ART.
- valenterry 2y ago
  Yep. Just like Clojure, Scala and others, depending on the flavor. Just language-wise there is little reason for Java. But tooling and ecosystem are of course also relevant.

bob1029 2y ago

I can't imagine not having this. All of the web development I do today relies heavily on server-side string interpolation (and verbatim) features. Being able to do things like evaluate functions and iterate collections inline with HTML templates has allowed me to sidestep a lot of pain over the years.

vips7L 2y ago
> Being able to do things like evaluate functions and iterate collections inline with HTML templates has allowed me to sidestep a lot of pain over the years. Every single templating engine supports this. It doesn't need to be built into the core language. Here's an example from JTE [0]: @import org.example.Page @param Page page <head> @if(page.getDescription() != null) <meta name="description" content="${page.getDescription()}"> @endif <title>${page.getTitle()}</title> </head> <body> <h1>${page.getTitle()}</h1> <p>Welcome to my example page!</p> </body> [0] https://jte.gg/#__tabbed_2_1 https://jte.gg/#__tabbed_2_1
- deleted 2y ago
  [deleted]

doikor 2y ago

It's strange as they point out that doing what Scala does is not possible as the language already has string literals that could contain the $ syntax stuff. But Scala does not enable string interpolation without explicitly using it by adding s infront of the string (s"some $value ${another}way") Though as they point out the syntax was not really the problem.

aster0id 2y ago

Why would anyone use java over kotlin for new projects? At least for server side development, kotlin has proved to be far superior to us.

bradboimler 2y ago
I find modern Java an absolute joy to program in. Kotlin doesn't solve any major problems I have with Java.
rmrfchik 2y ago
Because Kotlin as a mess language and have poor IDE support. $ kotlin Welcome to Kotlin version 1.6.10 (JRE 21.0.1+12-Debian-2) Type :help for help, :quit for quit >>> val b=ByteArray(1); >>> b[0] == 0; error: operator '==' cannot be applied to 'Byte' and 'Int' b[0] == 0; ^ $ jshell | Welcome to JShell -- Version 21.0.1 | For an introduction type: /help intro jshell> byte[] ba={0} ba ==> byte[1] { 0 } jshell> ba[0]==0 $2 ==> true upd: format
simon_void 2y ago
I prefer Kotlin over Java as well. I use it at work (where Java code has a tendency to become Kotlin code if it comes close to me) and at home. I'm looking forward to seeing how the native and wasm backends might extends the reach of Kotlin in the future.
DarkNova6 2y ago
Because syntax is the boring part of programming.
- Mesopropithecus 2y ago
  I agree with that, but null safety would be a big deal for correctness.
- favorited 2y ago
  Manually writing getters and setters is also pretty boring, in my experience.

DarkNova6 2y ago

Misleading Title. Actual title is: "Remove the String Templates preview feature" The feature is very much still in development. However, it's PREVIEW has been postponed.

hajimuz 2y ago

It’s under maintenance now. Kind of ironic.

ecopoesis 2y ago

This was always going to fail because the requirements were insane: solving SQL, XML and JSON generation should have never been part of the spec. There are hundreds, if not thousands of libraries for the those cases. The developers should have never tried to boil the ocean: simple Kotlin or Scala style interpolation with overloading `+` for concatenation is the 80% use case here. Yes it doesn’t do everything. But it makes life a lot more ergonomic. And they rejected this solution out of hand! So instead of something useful but not perfect we get nothing.