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:
Scala doesn't like:
Java doesn't like:
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):
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.
A nice presentation that may give some insights on subject is Sneaking Scala Into Your Organization by David Copeland.
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.
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.
