Migration de Java vers Scala

Question

Quels sont les points les plus importants à prendre en compte et les solutions de contournement, lorsque progressivement de la migration d'une base de code Java existant à la Scala? Avec un (potentiellement très longue) phase intermédiaire où les deux langues sont en usage.

Le genre de choses que je pense sont les suivants:

• différentes hiérarchies collection
• Java constructions que la Scala ne peut pas gérer bien
• Scala constructions qui ne sont pas pratiques à utiliser en Java
• construire des outils
• l'ordre de compilation
• l'immuabilité de soutien dans les cadres
• etc.

Answer 1

Scala n'aime pas:

• classes Java internes
• méthodes et variables statiques (en particulier dans les super classes)
• types bruts

Java n'aime pas:

• Caractéristiques des objets Scala
• fermetures
• acteurs (sauf Scarlett Johansson et Akka Actors puisqu'ils ont une API Java)
• implicites, en particulier les manifestes
• constructions de type avancé (types de type supérieur, types structurels, variables de type abstrait)

Answer 2

Dans un premier temps (c'est à dire la première phase de la migration), je dirais que vous ne voulez pas exporter une API (interface/méthode public, etc) avec un dur-à-utilisation-de-Java scala de construire.

Dans la pratique, je voudrais limiter l'exportation de tout ce qui est de la scala-spécifique (encore une fois, je parle de la première phase de la migration ici):

• scala bibliothèque de classes (types de fonction, collections etc)
• plus-kinded de type générique signatures
• implicites

Donc, ce n'est que de congé? Ainsi, la structure interne des classes (privé, méthodes, champs, etc) peuvent être convertis pour utiliser scala constructions et de la bibliothèque de classes.

Si vous avez des Api (surtout orientées client Api qui vous avez l'intention de migrer), je tiens à les concevoir à nouveau à partir du sol jusqu'à la Scala; d'abord, à l'aide d'un Java back-end. Alors je voudrais lentement ronger le code entre les deux.

Des points que vous avez soulignés, je suis d'accord que l'immuable paradigme de la Scala et de la mutable paradigme de Java ne se mélangent pas bien. Les autres points que j'ai trouvé moins problématique.

Un autre point principal de paradigme de non-concordance est la façon de convertir n'importe quel simultanées code (c'est à dire que ce qui rend l'utilisation de l' java.util.concurrent). Cela peut, bien sûr, être convertie comme est mais la question est de savoir si pour remplacer la simultanéité modèle basé autour de verrouillage avec un basé autour d' acteurs ou de la STM. Dans les deux cas, c'est également susceptible d'être une refonte complète, par opposition à une conversion en soi.

Answer 3

Une belle présentation qui peut donner un aperçu du sujet est Sneaking Scala Into Your Organization par David Copeland.

Answer 4

Un truc que j'aime à utiliser, je vais définir un objet à l'aide idiomatiques Scala propriétés (vals-les-bains et de vars), puis ajouter l' @BeanProperty d'annotation pour exposer ensuite JavaBean propriétés. De cette manière, chaque langue peut utiliser le natif d'expressions idiomatiques.

L' @BeanInfo d'annotation peut aussi être utilisé à un niveau de classe pour un objet analogue, mais vous devez être prudent ici - Lors de l'utilisation de @BeanInfo, toutes les méthodes que vous avez en outre la coutume définissent comme setXXX ou getXXX ne sont pas exposés via bean introspection. Ce qui est important, que vous avez à écrire manuellement les getters/setters pour les types de collection si vous aussi vous souhaitez gérer la traduction entre par exemple Scala Listes et Java Listes.

Answer 5

Je vais ajouter ce que les autres ont dit depuis qu'ils sont corrects et significatifs. Plus que juste le code, vous aurez besoin d'apporter plus de vos tests unitaires. Ce n'est pas son fort jusqu'à ce que vous commencez à changer la mutabilité et de structures de threading, bien que toujours essayer d'avoir tout fonctionne de la même manière comme il le faisait avant. Au cours de la transition, il est très important de conserver tous les cas de bord à l'esprit tout en découvrant de bord supplémentaire des cas, vous risquez d'introduire lors de la migration.

Si vous apportez vos tests unitaires dans un bon Scala framework de test comme ScalaTest avec une traduction directe, vous pouvez trouver que ce que vous êtes le test n'est pas ce que vous étiez en essai avant. Tout en faisant de la migration, il est important que vous gardiez à l'intention de l'ensemble du code avec des tests, plutôt que de permettre à la fragmentation de la pensée.