Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>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.</p> <p>In practice I would limit this to exporting anything which is scala-specific (again, I'm talking about the first phase of migration here):</p> <ul> <li>scala library classes (function types, collections etc)</li> <li>higher-kinded generic type signatures</li> <li>implicits</li> </ul> <p>So what does that leave? Well, the internals of classes (private methods, fields etc) can be converted to use scala constructs and library classes.</p> <p>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.</p> <p>Of the points you have highlighted, I would agree that the immutable <em>paradigm</em> of Scala and the <em>mutable</em> paradigm of Java do not mix well. The other points I have found less problematic.</p> <p>Another main point of paradigm-mismatch is how to convert any <strong>concurrent</strong> code you have (i.e. that which makes use of <code>java.util.concurrent</code>). This can, of course, be converted <em>as is</em> but the question is whether to replace the concurrency model based around locking with one based around <a href="http://en.wikipedia.org/wiki/Actors_%28concurrency%29" rel="nofollow">actors</a> or <a href="http://en.wikipedia.org/wiki/Software_transactional_memory" rel="nofollow">STM</a>. In either case, this is also likely to be a complete redesign, as opposed to a conversion <em>per se</em>.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload