<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<font size="4"><font face="monospace">There's a lot here; let me try
and excavate the actionable points. </font></font><br>
<br>
<blockquote type="cite" cite="mid:CAK6PxWMwzGjg0HJ9ym-BnrUDK4Kx6Oj_B355jMqG=GBJ+p1bMg@mail.gmail.com">
<p style="margin:0px;font-stretch:normal;font-size:12px;line-height:normal;font-family:".AppleSystemUIFontMonospaced"">##
The JSON example</p>
</blockquote>
<br>
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. <br>
<br>
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. <br>
<br>
<blockquote type="cite">just call `STR.process(st)` instead of
`st.interpolate()`</blockquote>
<br>
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? <br>
<br>
<blockquote type="cite" cite="mid:CAK6PxWMwzGjg0HJ9ym-BnrUDK4Kx6Oj_B355jMqG=GBJ+p1bMg@mail.gmail.com"><br>
<p style="margin:0px;font-stretch:normal;font-size:12px;line-height:normal;font-family:".AppleSystemUIFontMonospaced"">...
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!</p>
</blockquote>
<br>
This whole section seems an unnecessary detour, and kind of a big
distraction. <br>
<br>
<blockquote type="cite" cite="mid:CAK6PxWMwzGjg0HJ9ym-BnrUDK4Kx6Oj_B355jMqG=GBJ+p1bMg@mail.gmail.com">##
Can processors have methods?
<p style="margin:0px;font-stretch:normal;font-size:12px;line-height:normal;font-family:".AppleSystemUIFontMonospaced""><br>
</p>
<p style="margin:0px;font-stretch:normal;font-size:12px;line-height:normal;font-family:".AppleSystemUIFontMonospaced"">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:</p>
<p style="margin:0px;font-stretch:normal;font-size:12px;line-height:normal;font-family:".AppleSystemUIFontMonospaced""><br>
</p>
<p style="margin:0px;font-stretch:normal;font-size:12px;line-height:normal;font-family:".AppleSystemUIFontMonospaced"">Can
StringTemplate.Processor instances also just be used to invoke
methods on? </p>
</blockquote>
<br>
Of course; they're objects, and ST.P is just one interface they can
implement.<br>
<br>
<blockquote type="cite" cite="mid:CAK6PxWMwzGjg0HJ9ym-BnrUDK4Kx6Oj_B355jMqG=GBJ+p1bMg@mail.gmail.com">##
Please explain that caching thing</blockquote>
<br>
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. <br>
<br>
<blockquote type="cite" cite="mid:CAK6PxWMwzGjg0HJ9ym-BnrUDK4Kx6Oj_B355jMqG=GBJ+p1bMg@mail.gmail.com">
<p style="margin:0px;font-stretch:normal;font-size:12px;line-height:normal;font-family:".AppleSystemUIFontMonospaced"">Getting
back to the SQL example, there's a more fundamental itch to the
stated example. The example turns:</p>
<p style="margin:0px;font-stretch:normal;font-size:12px;line-height:normal;font-family:".AppleSystemUIFontMonospaced""><br>
</p>
<p style="margin:0px;font-stretch:normal;font-size:12px;line-height:normal;font-family:".AppleSystemUIFontMonospaced"">```</p>
<p style="margin:0px;font-stretch:normal;font-size:12px;line-height:normal;font-family:".AppleSystemUIFontMonospaced"">DB."SELECT
* from foo WHERE name = \{name}"</p>
<p style="margin:0px;font-stretch:normal;font-size:12px;line-height:normal;font-family:".AppleSystemUIFontMonospaced"">```</p>
<p style="margin:0px;font-stretch:normal;font-size:12px;line-height:normal;font-family:".AppleSystemUIFontMonospaced""><br>
</p>
<p style="margin:0px;font-stretch:normal;font-size:12px;line-height:normal;font-family:".AppleSystemUIFontMonospaced"">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).</p>
</blockquote>
<br>
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. <br>
<br>
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?<br>
<br>
<blockquote type="cite" cite="mid:CAK6PxWMwzGjg0HJ9ym-BnrUDK4Kx6Oj_B355jMqG=GBJ+p1bMg@mail.gmail.com">
<p style="margin:0px;font-stretch:normal;font-size:12px;line-height:normal;font-family:".AppleSystemUIFontMonospaced""><br>
</p>
<p style="margin:0px;font-stretch:normal;font-size:12px;line-height:normal;font-family:".AppleSystemUIFontMonospaced"">##
Compile time checking</p>
</blockquote>
<br>
Definitely a different topic :)<br>
<br>
<br>
</body>
</html>