Feedback: String Templates (JEP 430)

[Remi Forax]

> From: "Brian Goetz" <brian.goetz at oracle.com>
> To: "Duncan MacGregor" <duncan.macgregor at servicenow.com>, "amber-dev"
> <amber-dev at openjdk.java.net>
> Sent: Monday, April 3, 2023 2:33:58 PM
> Subject: Re: Feedback: String Templates (JEP 430)

> If you pull on this string a little more, you realize there is very little
> string left before you get to the knot labeled "compiler plugins". In order to
> get compile-time type checking for arbitrary template processors, the template
> processor class must be available at compile time, and the compiler must be
> willing to invoke it during compilation. While I realize there are lots of
> folks who think that would be a great thing, that's pretty far from the goal of
> this work.

> For processors like FMT, since they are specified in the JDK, IDEs can do much
> of the work here, and it is conceivable `javac` can have lint warnings that
> understand the format specifier.

> For arbitrary processors, annotation processors can add additional ad-hoc type
> checking.
The typechecking + call invokedynamic can also be implemented as a Leyden Condenser (once we have them). 
In that case, the typechecking is delayed until the image creation. 

I believe that if the template processor is implemented using a lazy static final [1] (so it's initialization does not depend of the execution of the static block), we can come with a condenser generic enough to work with all template processors. 

regards, 
Rémi 

[1] https://bugs.openjdk.org/browse/JDK-8209964 

> On 4/3/2023 6:41 AM, Duncan MacGregor wrote:

>> While I agree that compile time type checking and constants are a separate
>> topic, string templates, and especially the template formatter, seem like a
>> reasonable entry point to think about them as they rely on a new bit of syntax
>> and are being compiled to something special (an invoke dynamic based callsite
>> whose bootstrap takes the fragments and the method type). The problem I see at
>> the moment is that it’s not clear to me that the type information remains
>> available to the processor in a way that would make for compile time type
>> checking to be added later, and it would be a shame if we cut this path off
>> now. The ProcessorLinkage interface feels like it might be closer to path
>> allowing this, but I see that it’s sealed at the moment.

>> It would be sad if we can’t leverage a new way of string formatting to introduce
>> compile time type checking of those format strings when it feels like we’re
>> really close to being on a path that would enable it in a natural way.

>> Duncan.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20230403/bbb9f93a/attachment-0001.htm>