Migrating Java to Scala

Question

What are the most important points to be aware of, and the workarounds, when gradually migrating an existing Java codebase to Scala? With a (potentially very long) intermediate phase where both languages are in use.

The sort of things I'm thinking about are:

• different collection hierarchies
• Java constructs that Scala can't handle well
• Scala constructs that are impractical to use in Java
• build tools
• compilation order
• immutability support in frameworks
• etc.

Answer 1

Scala doesn't like:

• inner Java classes
• static methods and variables (especially in super classes)
• raw types

Java doesn't like:

• Scala objects traits
• closures
• actors (except Scarlett Johansson and Akka Actors since they have a Java API)
• implicits, especially Manifests
• advanced type constructs (higher kinded types, structural types, abstract type vars)

Answer 2

A nice presentation that may give some insights on subject is Sneaking Scala Into Your Organization by David Copeland.

Answer 3

I'll add to what others have said since they're correct and meaningful. More than just the code, you'll need to bring over your unit tests. This doesn't sound hard until you start changing mutability and threading constructs while still attempting to have everything work the same way as it did before. During the transition it's very important to keep all the edge cases in mind while discovering additional edge cases you may introduce during the migration.

If you bring your unit tests into a good Scala testing framework like ScalaTest with a direct translation you may find that what you are testing is not what you were testing before. While making your migration it's important that you keep the intent of the code together with the tests instead of allowing fragmentation of thought.

Answer 4

Initially (i.e. the first phase of migration), I would say that you don't want to export an API (interface/public method etc) with a hard-to-use-from-Java scala construct.

In practice I would limit this to exporting anything which is scala-specific (again, I'm talking about the first phase of migration here):

• scala library classes (function types, collections etc)
• higher-kinded generic type signatures
• implicits

So what does that leave? Well, the internals of classes (private methods, fields etc) can be converted to use scala constructs and library classes.

If you have any APIs (especially client-facing APIs which you intend to migrate), I would design them anew from the ground up in Scala; initially using a Java back-end. Then I would slowly eat away at the code inbetween.

Of the points you have highlighted, I would agree that the immutable paradigm of Scala and the mutable paradigm of Java do not mix well. The other points I have found less problematic.

Another main point of paradigm-mismatch is how to convert any concurrent code you have (i.e. that which makes use of java.util.concurrent). This can, of course, be converted as is but the question is whether to replace the concurrency model based around locking with one based around actors or STM. In either case, this is also likely to be a complete redesign, as opposed to a conversion per se.

Answer 5

One trick I like to use, I'll define an object using idiomatic Scala properties (vals and vars), then add the @BeanProperty annotation to expose then as JavaBean properties. That way, each language can use the native idioms.

The @BeanInfo annotation can also be used at a class level for a similar purpose, but you have to be careful here - When using @BeanInfo, any methods that you additionally custom-define as setXXX or getXXX won't be exposed via bean introspection. This is important, as you have to manually write getters/setters for collection types if you also want to handle translation between e.g. Scala Lists and Java Lists.