Rascunho da JEP: String Templates (Final)
A nova proposta de String Templates para o núcleo da linguagem Java está recebendo tanto elogios pelo seu design focado em segurança quanto críticas pela sintaxe incomum e verbosa (`STR."...\{x}..."`). Os defensores argumentam que processadores de template e a sintaxe `\{}` permitem construir de forma mais segura SQL, HTML, JSON e outras saídas estruturadas, afastando os desenvolvedores da interpolação bruta de strings e de riscos de injeção. Os críticos respondem que o recurso complica demais um problema que outras linguagens resolvem com interpolação mais simples, questionando se as trocas de ergonomia e as justificativas de compatibilidade retroativa valem o aumento de complexidade.
Recepção geral
- Muitos comemoram finalmente ter templates de string em Java e os veem como poderosos, especialmente com processadores personalizados e APIs com segurança de tipos (HTML, SQL, JSON).
- Uma parte substancial dos comentários considera o design “feio”, “superengenheirado” e verboso demais em comparação com outras linguagens (Kotlin, Python, JS, C#, etc.).
- Alguns argumentam que, apesar da justificativa de design, o caso comum (interpolação simples) agora ficou pior do que em outras भाषas e do que em idiomais existentes de Java.
Sintaxe: STR."..." e \{...}
- Forte crítica à sintaxe do receptor
STR.junto com\{expr}: visualmente poluída, confusa porque\tradicionalmente é uma escape, e fácil de ler erroneamente como escape de{em vez de início de interpolação. - Outros a defendem como consistente com Java:
\já significa “interpretação especial em um literal”;\{antes era ilegal, permitindo erros úteis em tempo de compilação quando um processador é omitido. - Alguns argumentam que, já que um processador como
STRé necessário de qualquer forma, usar\{}para compatibilidade retroativa é redundante;${}ou{}poderiam ter sido usados em vez disso. - Contra-argumento:
$é amplamente usado em ecossistemas de templating Java existentes, e torná-lo especial forçaria escapes e dor de migração.
Segurança e objetivos de design
- Os defensores enfatizam que o recurso não foi feito para ser mera interpolação de strings; ele foi projetado para combater vulnerabilidades de injeção ao:
- Tornar expressões de template chamadas de método em processadores tipados (por exemplo,
SQL."...",HTML."..."). - Permitir que bibliotecas recusem APIs de
Stringsimples e aceitem apenas tipos seguros produzidos por processadores.
- Tornar expressões de template chamadas de método em processadores tipados (por exemplo,
- Os críticos respondem que, na prática, a maioria dos desenvolvedores apenas usará
STR/FMTpara interpolação e continuará escrevendo SQL/HTML inseguros como strings.
Processadores de template personalizados / DSLs
- Alguns veem processadores definidos pelo usuário como uma grande vitória, semelhante a tagged templates do JavaScript e interpoladores do Scala, permitindo construtores seguros e específicos de domínio (SQL, HTML, JSON, XML).
- Outros temem a proliferação de mini-DSLs ad hoc, aumentando a carga cognitiva e o risco de manutenção.
- Alguns observam que recursos semelhantes em Scala e JS não levaram, de forma óbvia, a abuso generalizado.
Desempenho e ferramentas
- Preocupações levantadas sobre o custo de alocação (listas de valores) e a dependência de especialização por MethodHandle; as respostas observam que a especialização não se limita aos processadores embutidos.
- Alguns argumentam que a alegação de “nenhum custo extra de ferramentas” é exagerada, já que parsers/IDEs ainda precisam lidar com novas formas de expressão.