Borrador JEP: plantillas de cadenas (Final)
La nueva propuesta de Plantillas de Cadenas para el núcleo del lenguaje Java está recibiendo tanto elogios por su diseño centrado en la seguridad como críticas por su sintaxis inusual y verbosa (`STR."...\{x}..."`). Sus defensores argumentan que los procesadores de plantillas y la sintaxis `\{}` permiten construir de forma más segura SQL, HTML, JSON y otras salidas estructuradas, alejando a los desarrolladores de la interpolación de cadenas sin procesar y de los riesgos de inyección. Los críticos replican que la característica complica en exceso un problema que otros lenguajes resuelven con una interpolación más simple, y cuestionan si las concesiones de ergonomía y las justificaciones de compatibilidad hacia atrás compensan la complejidad añadida.
Recepción general
- Muchos celebran por fin tener plantillas de cadenas en Java y las ven como poderosas, especialmente con procesadores personalizados y APIs seguras por tipos (HTML, SQL, JSON).
- Una parte importante de los comentarios considera el diseño “feo”, “sobreingenierizado” y demasiado verboso en comparación con otros lenguajes (Kotlin, Python, JS, C#, etc.).
- Algunos argumentan que, pese a la justificación del diseño, el caso común (interpolación simple) ahora es peor que en otros lenguajes y que en los modismos existentes de Java.
Sintaxis: STR."..." y \{...}
- Fuerte crítica a la sintaxis
STR.más\{expr}: visualmente recargada, confusa porque\tradicionalmente es un escape, y fácil de leer erróneamente como una escapada de{en lugar de iniciar la interpolación. - Otros la defienden por ser coherente con Java:
\ya significa “interpretación especial en un literal”;\{antes era ilegal, lo que permitía errores de compilación útiles cuando se omite un procesador. - Algunos sostienen que, dado que de todos modos se requiere un procesador como
STR, usar\{}por compatibilidad hacia atrás es redundante; se podría haber usado${}o{}en su lugar. - Contraargumento:
$se usa ampliamente en ecosistemas de plantillas de Java ya existentes, y volverlo especial obligaría a escapar y supondría dolor de migración.
Seguridad y objetivos de diseño
- Los defensores destacan que la característica no está pensada para ser mera interpolación de cadenas; está diseñada para combatir vulnerabilidades de inyección mediante:
- Convertir las expresiones de plantilla en llamadas a métodos sobre procesadores tipados (p. ej.,
SQL."...",HTML."..."). - Permitir que las bibliotecas rechacen APIs de
Stringsin procesar y acepten solo tipos seguros producidos por procesadores.
- Convertir las expresiones de plantilla en llamadas a métodos sobre procesadores tipados (p. ej.,
- Los críticos responden que, en la práctica, la mayoría de los desarrolladores simplemente usarán
STR/FMTpara interpolación y seguirán escribiendo SQL/HTML inseguros como cadenas.
Procesadores de plantillas personalizados / DSLs
- Algunos ven los procesadores definidos por el usuario como una gran ventaja, similar a las plantillas etiquetadas de JavaScript y los interpoladores de Scala, que permiten constructores seguros y específicos del dominio (SQL, HTML, JSON, XML).
- Otros temen la proliferación de mini-DSLs ad hoc, aumentando la carga cognitiva y el riesgo de mantenimiento.
- Unos pocos señalan que características similares en Scala y JS no han llevado de forma evidente a un abuso generalizado.
Rendimiento y herramientas
- Se plantean preocupaciones sobre el coste de asignación (listas de valores) y la dependencia de la especialización de MethodHandle; las respuestas señalan que la especialización no se limita a los procesadores integrados.
- Algunos sostienen que la afirmación de “sin coste adicional de herramientas” está exagerada, ya que los parsers/IDEs igualmente deben manejar nuevas formas de expresión.