Migración de Java a Scala

Inicialmente (es decir, la primera fase de la migración), diría que no desea exportar una API (interfaz/método público, etc.) con una construcción scala difícil de usar desde Java.

En la práctica, limitaría esto a exportar cualquier cosa que sea específica de scala (de nuevo, estoy hablando de la primera fase de la migración aquí):

• clases de biblioteca scala (tipos de funciones, colecciones, etc.)
• firmas de tipo genéricas de mayor calidad
• implicita

Entonces qué deja eso? Bueno, los elementos internos de las clases (métodos privados, campos, etc.) se pueden convertir para usar construcciones scala y clases de biblioteca.

Si tiene alguna API (especialmente API orientadas al cliente que tiene la intención de migrar), las diseñaría de nuevo desde cero en Scala; inicialmente utilizando un back-end Java. Luego me comería lentamente el código entre ellos.

De los puntos que usted ha destacado, estoy de acuerdo en que el paradigma inmutable de Scala y el mutable paradigma de Java no se mezclan bien. Los otros puntos me han parecido menos problemáticos.

Otro punto principal de paradigm-mismatch es cómo convertir cualquier código concurrente que tenga (es decir, el que hace uso de java.util.concurrent). Esto puede, por supuesto, convertirse como es pero la cuestión es si reemplazar el modelo de concurrencia basado en el bloqueo por uno basado en actores o STM. En cualquier caso, esto también es probable que sea un completo rediseño, a diferencia de una conversión per se .

Una buena presentación que puede dar algunas ideas sobre el tema es Escabullirse Scala En Su Organización por David Copeland.

Un truco que me gusta usar, definiré un objeto usando propiedades idiomáticas de Scala (vals y vars), luego agregaré la anotación @BeanProperty para exponer luego como propiedades JavaBean. De esa manera, cada idioma puede usar los modismos nativos.

La anotación @BeanInfo también se puede usar a nivel de clase para un propósito similar, pero hay que tener cuidado aquí - Cuando se utiliza @BeanInfo, cualquier método que se defina adicionalmente como setXXX o getXXX no se expondrá a través de la introspección de bean. Esto es importante, como usted tiene que escribir manualmente getters / setters para los tipos de colección si también desea manejar la traducción entre, por ejemplo, Listas de Scala y Listas de Java.

Añadiré a lo que otros han dicho ya que son correctos y significativos. Más que solo el código, tendrá que traer sus pruebas unitarias. Esto no suena difícil hasta que comienzas a cambiar la mutabilidad y las construcciones de subprocesos mientras intentas que todo funcione de la misma manera que lo hacía antes. Durante la transición, es muy importante tener en cuenta todos los casos perimetrales mientras descubre casos perimetrales adicionales que puede introducir durante la migración.

Si usted trae su pruebas unitarias en un buen marco de pruebas de Scala como ScalaTest con una traducción directa, puede encontrar que lo que está probando no es lo que estaba probando antes. Mientras realiza su migración, es importante que mantenga la intención del código junto con las pruebas en lugar de permitir la fragmentación del pensamiento.