Índice de contenidos
Claves de la noticia
- Scala 3.10.0 ya está disponible como versión estable de la línea Scala Next, con cambios que pueden afectar a la compilación.
- El compilador deja de encontrar implícitos en objetos compañeros inaccesibles, un comportamiento que Scala 3.9 advertía con la opción de deprecación.
- La distribución incorpora Scala CLI 1.17.1, soporte de records de Java en patrones y paquetes .deb y .rpm.
Scala 3.10 ya tiene una versión estable: el proyecto publicó 3.10.0 este 12 de octubre a las 07:29 UTC en GitHub. Las notas incluyen novedades de lenguaje y herramientas, pero también una lista explícita de cambios incompatibles. Para equipos que mantienen aplicaciones y bibliotecas, el punto más urgente no es una sintaxis nueva: es revisar dependencias que hasta ahora obtenían implícitos desde un objeto al que el código consumidor no podía acceder.
Una advertencia de septiembre se convierte en bloqueo
El mecanismo de búsqueda de implícitos permite que el compilador suministre automáticamente ciertos valores necesarios para una operación. Parte de esa búsqueda se realiza en el objeto compañero de un tipo. Hasta ahora podía encontrar una instancia incluso si ese objeto era privado e inaccesible desde el punto donde se utilizaba. Así, una resolución automática podía funcionar mientras escribir la referencia equivalente de forma explícita producía un error.
La documentación de Scala 3.9 LTS, publicada el 3 de septiembre, anticipó el cambio: con la opción -deprecation, el compilador señalaba esas resoluciones, pero continuaba admitiéndolas. Scala 3.10 deja de encontrar las instancias inaccesibles. El cambio aplica una exigencia de accesibilidad ya presente en la especificación; su efecto práctico es que código anteriormente compilable puede dejar de serlo.
La propuesta integrada en el repositorio identifica precisamente ese alcance. No elimina todos los implícitos ni exige reescribir cualquier parámetro contextual. Afecta al caso donde la búsqueda encontraba una instancia que no estaba disponible para el llamante. Esa delimitación permite preparar la migración sin convertir un problema concreto en una alarma general sobre el lenguaje.
Al cruzar el aviso de 3.9 con las notas de 3.10 aparece una consecuencia operativa: si la instancia inaccesible vive en una dependencia, actualizar únicamente el proyecto consumidor puede no resolver el error. Puede ser necesaria una nueva publicación de la biblioteca que exponga correctamente la instancia. La documentación del proyecto ya señalaba esa dificultad y situaba alrededor de veinte proyectos afectados en su Open Community Build; ese recuento no representa el conjunto de aplicaciones Scala existentes.
Scala Next y LTS resuelven necesidades diferentes
Scala 3.10 continúa la línea Next. Scala 3.9 abrió en septiembre una nueva línea LTS, recomendada por el proyecto como base para autores de bibliotecas y usuarios de producción conservadores. La anterior LTS 3.3 conserva su propio calendario de mantenimiento. Que 3.10 sea estable no significa que sustituya automáticamente esas decisiones de soporte.
La documentación diferencia además la dirección de compatibilidad de los artefactos: una biblioteca publicada con 3.9 puede utilizarse desde posteriores versiones de esa línea y desde Next, mientras que los proyectos 3.3 no pueden consumir sin más bibliotecas publicadas con 3.9. No conviene mezclar esa relación entre versiones de artefactos con la compatibilidad del código fuente al recompilar.
Una aplicación puede necesitar revisar fuentes al cambiar de compilador aunque sus dependencias sean consumibles. A su vez, que una biblioteca compile con una versión nueva no garantiza que sus consumidores antiguos puedan utilizar los artefactos publicados. Compilar, ejecutar y publicar una biblioteca son tres comprobaciones distintas. Esa separación es especialmente útil cuando varios servicios comparten librerías internas y no migran todos en la misma entrega.
La actualización de herramientas refuerza la necesidad de fijar versiones: las notas de Scala CLI incluidas en el lanzamiento indican que la etiqueta lts resuelve ahora a la serie 3.9. Para mantener la serie anterior, se debe utilizar 3.3.lts. Un nombre genérico en una configuración no equivale a fijar indefinidamente una misma base.
Las novedades no tienen todas el mismo grado de estabilidad
La versión añade soporte para records de Java en el reconocimiento de patrones y acepta directivas de dependencias en el REPL, incluso acompañadas de código. También incorpora paquetes .deb y .rpm. Son mejoras concretas para interoperabilidad, sesiones interactivas y distribución; no prueban por sí solas una ganancia de rendimiento de las aplicaciones.
Las notas anuncian la activación predeterminada de strictEqualityPatternMatching y nuevos mecanismos de deprecación para indicadores de características de lenguaje. En paralelo, clasifican otras funciones como de previsualización, entre ellas el desenrollado de argumentos predeterminados para compatibilidad binaria y una sintaxis de lambda más relajada. Los traits especializados y otra propuesta de interfaces para agentes siguen en categoría experimental.
Esta clasificación importa al decidir qué incorporar en una biblioteca pública. Adoptar una función experimental impone una decisión distinta de utilizar una característica estabilizada. La disponibilidad en una versión estable del compilador no transforma todas las opciones que contiene en contratos de lenguaje igualmente consolidados.
Otros cambios incompatibles incluyen prohibir this en definiciones de nivel superior, convertir el operador de tipos with en error y sustituir determinadas conversiones de primitivas por métodos de extensión directos. El backend usa ASM estándar en lugar de la bifurcación anterior. Cada entrada debe contrastarse con el código del proyecto: las notas no justifican atribuir a todas las aplicaciones el mismo coste de migración.
Una migración útil empieza en 3.9, antes de cambiar la versión
Para el problema de accesibilidad, el primer diagnóstico documentado consiste en compilar con -deprecation en 3.9 y revisar las advertencias. Después puede probarse 3.10 en una rama, distinguiendo fallos en código propio de los que proceden de bibliotecas. Es un orden de comprobación basado en el aviso previo del proyecto, no una prueba que hayamos ejecutado sobre aplicaciones de terceros.
Conviene conservar pruebas de compilación y ejecución, además de revisar macros y configuración de publicación. La mejora del constant folding durante el inlining también figura entre los cambios incompatibles; el hilo de preparación del lanzamiento advertía de efectos sobre proyectos ZIO y apuntaba a una actualización de sus macros. Esa advertencia debe tratarse como contexto de migración, no como prueba de que toda aplicación ZIO falle hoy.
El cambio decisivo de Scala 3.10 es convertir algunas suposiciones antes toleradas en requisitos efectivos del compilador. La conclusión para quien mantiene bibliotecas es concreta: comprobar la accesibilidad de las instancias antes de publicar una actualización evita trasladar a sus consumidores un fallo que estos pueden no tener capacidad de corregir por sí solos.
Imagen: recreación conceptual generada para Tecnología Today sobre desarrollo de software; no muestra una interfaz real de Scala.
