Presentation at JCrete.org

[forax at univ-mlv.fr]

> From: "David Alayachew" <davidalayachew at gmail.com>
> To: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "Brian Goetz" <brian.goetz at oracle.com>, "amber-dev" <amber-dev at openjdk.org>
> Sent: Monday, July 24, 2023 12:32:16 AM
> Subject: Re: Presentation at JCrete.org

> Hello Rémi,

> > May i ask why ?

> > A logger process interpolated strings, combined with the
> > new shiny syntax of the template processor, make sense to
> > me.

> 1. Isn't the entire purpose of String interpolation to (safely) go from raw,
> unsanitized inputs into a fully formed String? Java allows us to go one step
> further and create output values other than a String, since doing so aligns
> perfectly with the broad goal of interpolation -- take raw inputs, sanitize
> them, and produce a clean, validated output. The JEP even says so in the final
> bullet of the goals section -- "Enable the creation of non-string values
> computed from literal text and embedded expressions without having to transit
> through an intermediate string representation." -- [
> https://openjdk.org/jeps/430 | https://openjdk.org/jeps/430 ]

> 2. And isn't the entire point why the Java team thought this was worth doing was
> not (just) because it was a simple boilerplate reduction, but because String
> interpolation is pretty much the front door for injection attacks? So, by
> attaching the "safe way" to the new shiny syntax, they have incentivized the
> right way for all developers.

> With both of those in mind, it becomes clear that mixing side effects with
> String interpolation makes String interpolation inherently unsafe.

[...] 

A call to a template processor is a method call (processor) to a Java object (StringTemplate.Processor). 
If we wanted to not have side effect, instead of using a OOP design we will have used a functional design, in this case a function call with an API closer to a varargs call (similar to what JavaScript does). 

I believe you have missunderstood how the validation works, there is a separation between the validation of the structure and the escaping of the values. 
The validation of the structure can be done once while the escaping has to be done for each call. 

For a logger, the validation depends on what we usually call an appender which is reponsible to transform the string template received by the logger to the correct format. 
By example, if an application is using a Time Series database like InfluxDB or Prometheus, the appender is responsible to encode the logging information to the right format using the TimeSeries client API. 

With a template processor and because most of the loggers in Java can change their configuration at runtime, ithe validation can be done once per configuration per appender. 

The problem of the template processor is not the syntax. It's not even the generated bytecode by javac. 
It's the implementation of the bootstrap method (see java.lang.runtime.TemplateRuntime) that 
- box all the values into a StringTemplate, storing all instances as Object in an array and all primitives as long in an another array, dropping the types nicely propagated by the compiler. 
So all calls using the themplate processor API are slow because of the boxing (the escape analysis is not able to recover this transformation if you take a look to the generated assembly code). 
- provides no way to do a different validation per callsite, so the validation has to done for each call (remember validation != escaping). 

There is a better API than the template processor API, FMT already uses it (StringTemplate.Processor.Linkage), but all other template processors can not use it. 

Rémi 

> Thank you for your time!
> David Alayachew

> On Sun, Jul 23, 2023 at 4:09 PM < [ mailto:forax at univ-mlv.fr | forax at univ-mlv.fr
> ] > wrote:

>> ----- Original Message -----
>>> From: "Brian Goetz" < [ mailto:brian.goetz at oracle.com | brian.goetz at oracle.com ]
>> > >
>>> To: "Remi Forax" < [ mailto:forax at univ-mlv.fr | forax at univ-mlv.fr ] >,
>> > "amber-dev" < [ mailto:amber-dev at openjdk.org | amber-dev at openjdk.org ] >
>> > Sent: Sunday, July 23, 2023 3:12:22 AM
>> > Subject: Re: Presentation at JCrete.org

>> >> So I don't believe a logger based on a template processor makes sense at least
>> >> not until StringTemplate.Processor.Linkage becomes non-sealed.

>> > I'll take this further: I don't think a logger based on a template
>> > processor makes sense *at all*.

>> May i ask why ?

>> A logger process interpolated strings, combined with the new shiny syntax of the
>> template processor, make sense to me.

>> And this is a slipery slope, if we have good template processor and bad template
>> processor, how to recognize a good template processor from a bad one ?

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