Feedback: String Templates (JEP 430)

[Remi Forax]

> From: "Reinier Zwitserloot" <reinier at projectlombok.org>
> To: "amber-dev" <amber-dev at openjdk.java.net>
> Cc: "Brian Goetz" <brian.goetz at oracle.com>
> Sent: Friday, March 31, 2023 7:11:34 PM
> Subject: Re: Feedback: String Templates (JEP 430)

> On 31 Mar 2023 at 17:37:00, Brian Goetz < [ mailto:brian.goetz at oracle.com |
> brian.goetz at oracle.com ] > wrote:

>> The examples here are intended to motivate why the design is as it is, and
>> illustrate the sort of use cases we have in mind.

> For the JSON example, it’s just an oversimplification in the example code, but,
> some sort of callout that the example code is oversimplified so much it’s now
> insecure is warranted, no? Or just remove the implementation code, given that
> it isn’t all that illustrative - the example works just fine without it, given
> that the call-site code is the key part of the example. Just a minor nit.

>>> just call `STR.process(st)` instead of `st.interpolate()`
>> Your point here is, I think, that the `interpolate` is an "attractive nuisance",
>> and will make it too easy for people to do the wrong thing without thinking. A
>> valid concern, but on the other hand, is the extra step going to deter those
>> folks?

> I think it’ll deter a significant amount. The obvious place to look for ‘how do
> I String Template Processor’ is, at least in my experience, the same place
> folks look for just about any other API: The methods directly available on
> StringTemplate . The easy action to take, once someone has decided to write a
> processor, is to let the IDE generate the required signature, and then
> auto-complete the available parameters and methods from there. By removing
> interpolate() from that lowest-effort flow, you force someone to go out and
> look for it, which gives them some time to think and stands at least some
> chance of highlighting the security implications of st.interpolate() /
> STR.process(st) .

> This is always a very tough discussion: How much should the language design
> prevent silly mistakes. On one hand, perfection is quite impossible: The
> universe is far too good at coming up with incompetence, there is no way to
> stop all foreseeable abuse of an API, and therefore, that cannot be a goal.
> However, making an API where the obvious way to use it is subtly but
> dangerously incorrect, is, and surely this requires no debate, bad API design.
> The trick is figuring out where to draw the line. Especially considering that
> interpolate() can always be added later, but if added, cannot be removed, I
> recommend not including it in the first release of this API. The javadoc of
> Processor and/or StringTemplate itself should explain how one can interpolate
> (by using STR.process(st) ), with all due warnings about the dangers of doing
> so.

I agree that interpolate() is too easy to misuse but at the same time, it's a useful primitive. 
I wonder if the solution is to add an escape function, a function that takes an Object and returns an Object that should escape the values to interpolate. 

Something like 
public String StringTemplate.interpolate(UnaryOperator<Object> escapeFunction) { ... } 

By asking for an escape function, we are making the API safer to use. 

Rémi 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20230331/bc6eec04/attachment.htm>