Java still inexplicably doesn't have first-class support for string interpolation/templates. They were slated to add it in Java 23, but they removed it from the preview and it hasn't been seen since.
Also who cares having to use String.format() in the agentic coding age?
It's the trivial cases that are compile time. The interesting templating is done with input that isn't defined within the source, and those can't be run entirely at compile time.
> And you automatically get things like safe SQL queries with parameter binding instead of injection vulnerabilities.
That's been solved for decades with parameterized queries (binding variables), and doesn't require interpolation in any way (at least not in the context we're using it here, but probably not at all in most DB drivers and engines). In fact, I would go so far as to say if someone is trying to use string interpolation instead of parameterized queries to avoid SQL injection, they've fundamentally misunderstood the problem and are trying to solve it at the wrong layer.
Also, if the string interpolation for the query is done at compile time, what type of content known at compile time is something that we'd be worried about SQL injection being in?
SQL doesn't require interpolation, but it's much cleaner to write it that way and not have to explicitly do binding. It's not an "instead." Like I said, what the interpolator does is automatic safe binding with interpolation syntax.
The content known at compile time is the query template that you're binding. The point is a compile-time interpolator turns e.g. `sql"""select * from users where name=$name"""` into `Statement("select * from users where name=?").bind(name)`.
You can also have macro fragments as "inline def" functions in e.g. Scala so that they compose naturally. c.f. Quill[0].
The thing that tends to be expensive for compilation, at least in Scala, is automatic recursive typeclass instance derivation. And even that one can be mitigated by just manually writing e.g. `implicit val jsonDecoder = JsonDecoder.derive[MyClass]` for each class. Otherwise compilation isn't an issue IME. Again, the time saved being able to work in "if it compiles, it works" mode easily dwarfs the time spent compiling.
And clearly a lot of work and time went into it with the previews.
The fact that they pulled it back suggests they looked down deep into an abyss that looked back at them, and what they saw scared them.
I don't know if there has been a published deep dive post mortem on the whole string templating thing, but I am quite comfortable with the team yanking it out if they felt it wasn't right.
Maybe there is something on the mailing lists.
It's a very conservative language that wants to minimize breakage, and the tradeoff is not without costs. I would argue than in LLM-world, the right tradeoffs change, but I don't think a language like Java is going to assume everyone has an LLM to do migrations for free any time soon.