異なるリリース間でScalaバイナリに互換性がないのはなぜですか?
6 に答える
トレイトはインターフェイスのようなものですが、実装を含めることができるため、トレイトのコンパイル方法と関係があります。これにより、ソースの互換性を損なうことなく、バイナリの互換性を損なう変更を簡単に行うことができます。実装とともに新しいメソッドをトレイトに追加する場合、そのトレイトを実装するすべてのものを再コンパイルして、その実装をピックアップします。おそらく他の問題もあるでしょうが、それらはほとんど同じ線に沿っていると思います。
言及された特性などのScala固有の機能に対するJVMサポートの欠如、およびそれが活発に進化しているという事実。
問題を引き起こす特定の言語の問題を理解したい場合は、これの背景をOderskyから直接説明します。
http://www.scala-lang.org/node/9346
この問題に不慣れで、これがアプリケーションに与える影響を理解したい場合は、DavidPollackからのこの投稿と併せて読む価値があります。
japi-compliance-checker 1.6でScalaのサポートを実装し、Scalaのすべてのバージョン(バイナリ互換性とソース互換性の両方)の下位互換性の分析を実行しました。
これで、重大な変更を詳細に表示できます。レポートはここから入手できます:http://abi-laboratory.pro/java/tracker/timeline/scala/
レポートは1日おきに更新されるため、Scalaの最近のバージョンの変更を監視できます。
それはまだ比較的若く、活発な開発が行われています。
新しいリリースには、待ち望まれていた多くの問題に役立ついくつかの変更がありますが、下位互換性を持たせることはできませんでした。
Sunは更新に関して一種の制限があるため、Javaの変更はかなり遅く、通常は苦い終わりとの下位互換性を維持しようとします。これが進歩の妨げになることもありますが、大企業は安定した言語が大好きです。
一方、Scalaは少数の学者グループの手に渡っており、業界では(まだ)広く使用されていないため、変更に応じて自由度が増します(または取得します)。
うーん、いや。あなたの事実をまっすぐにしてください。2.7.2.3b1-> 2.7.2.3b2に移行する場合、再コンパイルは必要ありませんでした*。これは、2.7.2.3b1の機能を使用して定着したレガシーコードを使用していた大規模な顧客ベースのため、私にとって本当に安心でした。
*警告-scala.collection._またはscala.xml._のコードを愚かに使用した場合を除きます