First, the lesson of Log4Shell have not been learnt. Allowing more libraries to do formatting, what can go wrong ?
And String.format() is slow because every values are boxed. This JEP repeats the same mistake with the templates.
As to boxing, the built-in template processors, STR and FMT, don't do boxing (they use MethodHandle mechanisms similar to those used by lambdas) -- FMT is ~40x faster than String.format, I'm told -- but that capability hasn't been exposed as an API yet. As with other features, we try exposing basic usages first, and more sophisticated ones later.
I don't have the same definition of security (i've read the JEP). Unlike TypeScript, you can not type the template values.
> built-in template processors, STR and FMT, don't do boxing ...
but all the others user-defined template processors (think a logger) are second class citizens and will do boxing.
Efficient String interpolation is hard without macros, that's why it's a macro in Rust.
This JEP tries to solve a harder problem, user defined template processors but do not provide the tool to make them efficient and never will. Are you suggesting that there is a JEP about macros in the making ?
Not quite. It is hard without some compile-time computation, but what's compile-time for languages relying on AOT compilation (and requires macros or compile-time introspection as in Zig), happens at runtime in Java because that's when the optimising compilation happens, and Java has a user-exposed mechanism for defining call-sites (https://docs.oracle.com/en/java/javase/19/docs/api/java.base...). It's just that, as with most of our new features, we expose a simple API first and a sophisticated API later. No need for macros.