<i18n dev> RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v7]

[Rémi Forax]

On Wed, 2 Nov 2022 18:27:30 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransLiterals.java line 429:
>> 
>>> 427:         }
>>> 428: 
>>> 429:         private JCClassDecl newStringTemplateClass() {
>> 
>> I find it weird to have the compiler emit an implementation of StringTemplate just to capture what is there in the code. If there are many usages of string templates, this could lead to a proliferation of synthetic classes. Perhaps we should consider using a metafactory here, like we do for lambdas, so that we can return some private JDK StringTemplate implementation type.
>
> The main consideration is performance. I spent quite a bit of time playing around with different implementations including metafactories (hence the carrier class work.) Since a majority of use cases will be STR and FMT, the number of classes will likely be just a few per application. Because of the change to force processor always, I will be revisiting this during the preview period to work on other solutions (I mentioned ProcessorFactories/ProcessorBuilders earlier).

@JimLaskey, someone will implement a LOG at some point in the future and you will get many template classes per application class.
You mention the carrier but i believe you can implement something similar to a carrier erasing the type of the values but without using method handles to try to make it type safe and instead pass the real types as a class data of a hidden class and later as a type argument once the reified generics will be released.

-------------

PR: https://git.openjdk.org/jdk/pull/10889