On Wed, 2 Nov 2022 18:27:30 GMT, Jim Laskey <[email protected]> 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
