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

[Jim Laskey]

On Tue, 1 Nov 2022 12:57:03 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add @SafeVarargs declarations
>
> 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).

> src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 244:
> 
>> 242:      *     mode |= NOLAMBDA     : lambdas are not allowed
>> 243:      */
>> 244:     protected static final int EXPR          = 1 << 0;
> 
> I note how many of the changes in this class are "stylistic" - e.g. replacing direct manipulation of state bits with method calls. While I'm not opposed to it, this is something rather orthogonal to what's being discussed here (perhaps we should consider factoring it out?)

I agree. I haven't updated uses by others, so it would be good to coordinate.

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

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