New candidate JEP: 430: String Templates (Preview)
Eric Bresie
ebresie at gmail.com
Wed Sep 21 23:45:05 UTC 2022
Just curious, doesn’t JSP/JSF processing already use a “string template” type paradigm using a ${} type syntax. Would any changes here be usable either or or there?
Given recent log4j security issues, is there any possible risk that expansion could introduce some exploitable logic? Does any sort of constraint or mechanism need to protect against that or am I I er thinking it?
Get Outlook for iOS<https://aka.ms/o0ukef>
________________________________
From: jdk-dev <jdk-dev-retn at openjdk.org> on behalf of Attila Kelemen <attila.kelemen85 at gmail.com>
Sent: Wednesday, September 21, 2022 6:20 PM
To: Brian Goetz <brian.goetz at oracle.com>
Cc: amber-dev at openjdk.org <amber-dev at openjdk.org>; jdk-dev at openjdk.org <jdk-dev at openjdk.org>
Subject: Re: New candidate JEP: 430: String Templates (Preview)
Thanks for the responses. See some of my clarifications below.
> >
> > 1. Might be a personal preference, but I find the
> > `TemplateProcessorExpression . Template` syntax bizarre.
>
> We knew that at least one out of the 10M Java developers would loudly
> proclaim "I hate the syntax", so congratulations, it's you :) New
> syntaxes are risky; people are used to "${foo}" in other languages, and
> this is new and different, and sometimes different is scary. But, it
> wasn't picked out of a hat; a good deal of thought has gone into this,
> and so while it may seem weird now, give it a year and I suspect it will
> not seem so odd. (In any case, amber-dev isn't the forum for syntax
> discussions, so let's leave this here.)
Just to clear the misunderstanding: I was not commenting on the "\{foo}",
I consider that a good thing (better than "${foo}" for sure, and "${foo}"
would not even be a compatible change). I was talking about the:
`STR."bla ${myVar} bla"`. As opposed to just calling the respective methods.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20220921/c358aa52/attachment-0001.htm>
More information about the amber-dev
mailing list