Feedback: String Templates (JEP 430)

Brian Goetz brian.goetz at oracle.com
Mon Apr 3 12:33:58 UTC 2023


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.


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/6ed6985e/attachment.htm>


More information about the amber-dev mailing list