On Tue, 1 Nov 2022 12:57:03 GMT, Maurizio Cimadamore <[email protected]>
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
