既存のJavaコードベースをScalaに段階的に移行する場合、知っておくべき最も重要なポイントと回避策は何ですか?両方の言語が使用されている(潜在的に非常に長い)中間フェーズ。
私が考えていることの種類は次のとおりです。
- さまざまなコレクション階層
- Scalaがうまく処理できないJavaコンストラクト
- Javaでの使用が実用的でないScalaコンストラクト
- ビルドツール
- コンパイル順序
- フレームワークでの不変性のサポート
- 等
既存のJavaコードベースをScalaに段階的に移行する場合、知っておくべき最も重要なポイントと回避策は何ですか?両方の言語が使用されている(潜在的に非常に長い)中間フェーズ。
私が考えていることの種類は次のとおりです。
Scalaは好きではありません:
Javaは好きではありません:
最初は(つまり、移行の最初のフェーズ)、Javaから使用するのが難しいscalaコンストラクトを使用してAPI(インターフェース/パブリックメソッドなど)をエクスポートしたくないと思います。
実際には、これをscala固有のもののエクスポートに制限します(ここでも、移行の最初のフェーズについて話します)。
それで、それは何を残しますか?クラスの内部(プライベートメソッド、フィールドなど)は、scala構造とライブラリクラスを使用するように変換できます。
API(特に移行する予定のクライアント向けAPI)がある場合は、Scalaでゼロから新たに設計します。最初はJavaバックエンドを使用します。それから私はその間のコードをゆっくりと食べてしまいました。
あなたが強調した点の中で、Scalaの不変のパラダイムとJavaの不変のパラダイムがうまく混ざっていないことに同意します。私が見つけた他の点はそれほど問題ではありません。
パラダイムの不一致のもう1つの主要なポイントは、所有している並行コード(つまり、を利用するコード)をどのように変換するかですjava.util.concurrent
。もちろん、これはそのまま変換できますが、問題は、ロックに基づく並行性モデルを、アクターまたはSTMに基づく並行性モデルに置き換えるかどうかです。いずれの場合も、変換自体ではなく、これも完全な再設計である可能性があります。
このテーマについての洞察を与える良いプレゼンテーションは、David Copeland によるSneaking Scala Into Your Organizationです。
私が使用したいトリックの1つは、慣用的なScalaプロパティ(valsとvars)を使用してオブジェクトを定義し、@BeanProperty
アノテーションを追加してJavaBeanプロパティとして公開します。そうすれば、各言語でネイティブイディオムを使用できます。
アノテーションは@BeanInfo
クラスレベルでも同様の目的で使用できますが、ここで注意する必要があります-@BeanInfoを使用する場合、setXXXまたはgetXXXとして追加でカスタム定義したメソッドは、Beanイントロスペクションによって公開されません。ScalaリストとJavaリストなどの間の変換も処理する場合は、コレクションタイプのゲッター/セッターを手動で作成する必要があるため、これは重要です。
他の人が言ったことは正しくて意味があるので、追加します。コードだけでなく、単体テストを引き継ぐ必要があります。これは、以前と同じようにすべてを機能させようとしながら、可変性とスレッド構成を変更し始めるまでは難しいことではありません。移行中は、移行中に導入される可能性のある追加のエッジ ケースを発見しながら、すべてのエッジ ケースを念頭に置くことが非常に重要です。
単体テストを ScalaTest のような優れた Scala テスト フレームワークに直接変換して持ち込むと、テストしているものが以前にテストしていたものではないことに気付く場合があります。移行を行っている間は、思考の断片化を許すのではなく、テストと共にコードの意図を維持することが重要です。