Feedback: String Templates (JEP 430)

[Brian Goetz]

There's a lot here; let me try and excavate the actionable points.

> ## The JSON example
>

My take-away here is "the JEP text suggests that JSON document creation 
is mere interpolation, and it should remind the audience that injection 
attacks are as big a concern in JSON as in SQL." This is worth considering.

As you know, the examples surrounding JSON and JDBC, are just examples.  
This JEP doesn't specify processors for these domains; that's a separate 
effort, some of which will probably happen in the JDK, and some of which 
will happen in the broader ecosystem.  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.

> 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?

>
> ... but while we're here, the entire of method seems pointless. After 
> all, Processor is, itself, a functional interface, so we can just 
> delete the `StringTemplate.Processor.of()` part of the above snippet 
> and it would exactly the same way!
>

This whole section seems an unnecessary detour, and kind of a big 
distraction.

> ## Can processors have methods?
>
>
> We have some more pointed comments about the SQL examples, but, it 
> also raises an interesting use case that we think just works as is, 
> though the proposal doesn't explicitly spell it out:
>
>
> Can StringTemplate.Processor instances also just be used to invoke 
> methods on?
>

Of course; they're objects, and ST.P is just one interface they can 
implement.

> ## Please explain that caching thing

This is a valid thing to wonder about, and we can discuss it separately, 
but it's not really what the JEP should be focused on. While the role of 
the JEP changes over the lifecycle of a feature, at this stage, where 
the feature is ready to be delivered, its primary role is outlining what 
was implemented, with some supporting "why".  Including a "Processor 
Writer's Guide" here would be out of scope, and interfere with the 
primary role of the JEP.

> Getting back to the SQL example, there's a more fundamental itch to 
> the stated example. The example turns:
>
>
> ```
>
> DB."SELECT * from foo WHERE name = \{name}"
>
> ```
>
>
> into a `java.sql.ResultSet` object. This is.. contrary to the spirit 
> of JDBC, which acknowledges that the step of turning a string literal 
> into a `PreparedStatement` is on its own such a (potentially!) 
> expensive step, that the PS is, itself, a __resource__ that needs to 
> be separately closed (unless you rely on the mechanism where closing a 
> Connection closes all resources that you spawned from it).
>

As mentioned, the motivating examples are just that: motivating 
examples.   There is ample time to discuss the API of a future proposed 
SQL processor for the JDK, if and when we do one.

But, I'm having a hard time distilling your actual concern here.  Is it 
that you think the language feature is flawed in that it cannot express 
what you think is the right way to do it, or are you simply worried that 
people will take the examples as blessing of "here's a good way to do 
something in XYZ domain", and blindly follow it?

>
> ## Compile time checking
>

Definitely a different topic :)

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