Java string interpolation feature has been cancelled | Hacker News Reader

Java string interpolation feature has been cancelled

mail.openjdk.org

71 pointsneonsunset114 comments

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/kz48f...

Brian Goetz is one of the Java language&JDK architects.

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

I think he's referring to this discussion: https://mail.openjdk.org/pipermail/amber-spec-experts/2024-A...

Thanks! We've changed the top link to that from https://bugs.openjdk.org/browse/JDK-8329949, which is mostly just a pointer.

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.

Yeah lots of bikeshedding over \ instead of $ was just really unnecessary.

This might be a better post. Brian's original email is here.

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

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.

This could be supported with String constructor with StringTemplate overload.

    String str = new String("Hello \{name}");

OR just add a .interpolate() function

    String str = "Hello \{name}".interpolate(); // verbose
    String str = "Hello \{name}".join(); // less verbose, but less representative

OR probably at the bottom of the list of recommendations

    String str = "Hello \{name}".toString() // matches StringBuilder behaviour

Knowing Java devs, also a non-zero chance it becomes

    String str = "Hello \{name}".toUnsafeString()

Quoting Brian:

> shed to be painted (but please, not right now.).

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.

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.

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.

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.

"We discovered, unfortunately quite late in the game, that the design was flawed."

That's an explanation of why the feature was pulled, not of why it was problematic in its current form.

That doesn't clear anything up.

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.

You know Go has generics right? They took the time to get them right, but then they did.

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.

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.

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.

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/Refe...

[1]: 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.)

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

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.

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.

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.

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

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.

> 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

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

Luckily there is Kotlin that gives programmers a nicer interface to the JVM.

While not taking advantage of all its features, because Android/ART.

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.

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.

Not canceled! Just postponed. Pleased fix the headline

mirror: https://web.archive.org/web/20240618081036/https://bugs.open...

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.

Because syntax is the boring part of programming.

They also had nice features like conditional type inference right ?

Kotlin has type inference and smart-casting, which i guess is what you mean!?

Most probably, sorry I lost track of languages changelog there's so many of them these days.

Just saying, kotlin wasn't just a more aesthetically pleasing java, there were some deeper benefits as far as i can tell.

I agree with that, but null safety would be a big deal for correctness.

Manually writing getters and setters is also pretty boring, in my experience.

That's purely your choice on the libraries you use. Nothing in the language is forcing you to do this. Getter/setters are just a requirement of JPA which you don't have to use. In fact if you just use jOOQ or query dsl you can map to Java records.

The language isn't forcing it, but idiomatic Java (and decades of Java-based university training) is. Pretty much every professional Java project I've ever seen is full of code like:

  private Map<String, Client> clients;
  
  public Map<String, Client> getClients() {
    return clients;
  }
  
  public void setClients(Map<String, Client> clients) {
    this.clients = clients;
  }

Kotlin's approach, where you declare and instantiate a property, and the getter/setter/backing storage are synthesized for you, is vastly preferable to me:

  public var clients = emptyMap<String, Client>()

I just disagree. This is not idiomatic Java; it's idiomatic JPA. All of the Java I see professionally and in the community uses immutable classes when not dealing with JPA entities.

I guess you live in a more modern workspace than I do. I just picked an open source project that (A) I know we use at work, and (B) I know is written in Java. I picked a random source file that sounded like it would have some mutable state, and the very first functions below the constructor were a trivial getter and setter around a private ivar.

https://github.com/apache/solr/blob/main/solr/core/src/java/...

I'm a little surprised it was in literally the first place I looked, but I'm not surprised that it was easy to find. "Use private ivars and write getters and setters to encapsulate your state" was probably the second thing that a generation of CompSci students learned in their first programming class, right after "an object is an instance of a class."

You picked a project that (A) is literally older than the sun, (B) targets Java 11, a version from 5 years ago, and (C) the file is generated.

Right at the top of the file...

> /* QueryParser.java / / Generated By:JavaCC: Do not edit this line. QueryParser.java */

I'm not claiming you're not going to see properties written out. I'm just saying that's not the majority of code you're going to see and to claim that idiomatic Java is all getters and setters is a bit far fetched.

Here is what I would consider modern idiomatic Java, immutable records and immutable classes that may expose some of their state:

https://github.com/jstachio/jstachio/blob/main/compiler/apt/... https://github.com/jstachio/jstachio/blob/main/compiler/apt/...

Kotlin’s approach was a necessity to interact with a Java convention. Java instead tries to move away from that mutable convention to an immutable-preferring one with clearer rules (e.g. what is the correct setter and getter for an `IP` field?).

You would be a fool to do exactly that. Use Lombok, or even better: immutable records.

Setters are needed in exceedingly rarely circumstances.

Can your IDE write them for you?

It's definitely not limited to the server side of things. Obviously it's the standard for Android app development and, largely, a pleasure to work with.

Because Kotlin is a guest language, designed to sell InteliJ.

Like C (alongside C++) and UNIX, JavaScript and Web, CLR and C#, JVM and Java are designed together, and have first class tooling in all Java IDEs.

At work I use Kotlin. At home I often use Java.

My main reason for using it for my personal hobby projects is because I prefer another IDE.

And Kotlin is only supported by IntelliJ, which I admit is a really good ide, but not my favorite.

There are Kotlin plugins for Eclipse, VS Code, NetBeans, etc...

Last I checked they only did syntax highlighting, not completion. And Jetbrains were rather clear that it was not a priority.

I am happy to be wrong now though.

Edit, this is a good step forward, here is the list from NetBeans, the "Toyota Hilux" of IDEs and my favorite:

    Language Feature Support Status
    File type recognition √
    Project type 
    Semantic syntax highlighting √
    Formatting √
    Braces matching √
    Code completion √
    Error Hints/Fixes/Suggestions 
    Code templates 
    Refactoring 
    Debugging

At the pace this is moving now I don't know what will stop me from only using Kotlin in the feature.

The VS Code Kotlin plugin also supports the following:

Code completion

Linting

Semantic highlighting

Debugging

Go-to-definition

Signature help

Hover

Formatting

Document symbols

Find references

Can you share plugin for NetBeans? Last time I checked it was some outdated plugin from JetBrains (who, obviously, aren't interested in any other IDE).

I find modern Java an absolute joy to program in. Kotlin doesn't solve any major problems I have with Java.

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

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.

It’s just an unsolved problem in computer science.

String templates?

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.

How does it differ from just concatenating?

You don’t want to just concatenate Little Bobby tables.

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.

Definitely possible: https://learn.microsoft.com/en-us/ef/core/querying/sql-queri...

Exactly. A specific API. Foe SQL that is good, but for smaller things a proper interpolation thing is great.

I was just showcasing that you can have both - there is regular string interpolation and there are APIs to accept interpolated expressions and then handle them arbitrarily (you can't pass a regular string produced by an interpolation to FromSql(expr), only to FromSqlRaw which makes IDE yell at you to make sure you know what you are doing), without even having to materialize the string if that isn't the intention.

Java ended up having neither which seems rather extreme.

null backward incompatibility might sneak up and become a horrifying null to pay.

---

"{warning} backward incompatibility might sneak up and become a horrifying $price to pay."

JavaScript solved that by using a new string delimiter for interpolated strings (`). C# solved it by preceding interpolated strings with a $ prefix.

> The site is currently under maintenance. Please come back again later.

What's this about?

They are compiling the JSPs. Wait a bit.

Compiling and executing jsp is still one of the most efficient way to template a web page. Although, not the most safe by default.

I know, I was joking.

I however have some PSTD from University times..

kotlinx.html is where it's at. Generally clean (though a few rough edges.)

I'm more for the approach used by JTE

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.

If I were them, I'd interpolate that message a bit.

But cancelling that ability seems to be what the fuss is about.

HN hug of death, I assume.

Most of the information is in this email: https://mail.openjdk.org/pipermail/amber-spec-experts/2024-A...

Oh, string templates. That's a shame. Seemed like one of the new features that'd actually be useful

Are you implying that other new features are not useful? Could you elaborate, because I think a lot of the stuff being added (records, pattern matching) is super useful.

So, the new design has smaller API surface area and more possibilities for late binding, that's nice.

Could be also just security patching. Atlassian just published their monthly security bulletin with some serve Jira DC vulnerabilities.

ref https://confluence.atlassian.com/security/security-bulletin-...

It’s under maintenance now. Kind of ironic.

Reply on news.ycombinator.com