scala-lang.orgのニュースの翻訳です(翻訳:mhanada) 原文
Scala 2.12ではJava8が必須になります。この移行をできるだけスムーズにするためのプランを以下に記します。
目標
- ユーザとライブラリのメンテナ、双方の移行の手間を最小限にする。
- Java6のサポートをもう少し延長する(Scala 2.11のみ)。
- Javaプラットフォームの改善に追従する。
方法
- 今後の2.11.xリリースで以下の実験的機能を導入する(要フラグ):
- Java 8スタイルのクロージャのコンパイル
- Miguelの新しいバックエンドとオプティマイザ
- 完全なソースコードの後方互換性を確保して2.11と2.12のクロスビルドを簡単にできるようにする(非推奨メソッドの削除はしない予定ですが、オプションで非推奨エラーを出さないようにできます)。2.11と2.12でコンパイラと標準ライブラリのコードベースを緊密に連携させる。
- Scala 2.12の公式ディストリビューションはJava 8用にビルドする(従ってJava 8が必要)。新しいバックエンド(とオプティマイザ)がデフォルトになります。
背景
- これ以上のartifactIdの混乱なしに異なる2つのバージョンのJavaに向けた、Scalaの単一バイナリを保守することはできません。必要なJavaのバージョンをMavenが指定できるようになったとしても、この分岐はエコシステムにとって大きな重荷になるでしょう。従って、必要とするJavaのバージョンごとにScalaの(バイナリ)バージョンを分ける必要があります。
- 同じコミュニティビルドをそれぞれのバージョンで実行することで、2.11と2.12のクロスビルドをチェックする予定です。ソースの後方互換性を向上させるため、Sacala 2.12では非推奨のメンバは削除されません。ですが、2.12コンパイラは(標準では)2.11.0以前の非推奨メンバーを使用するとエラーを出します。(原則として、もし2.12のライブラリをJava6用にコンパイルするとしたら2.11とバイナリ互換性を持つべきです)
- クロージャをJava 8のメソッドハンドルベースでサポートしてもパフォーマンス上の大きなメリットすぐには出ないかもしれません(確実にバイトコードのサイズ、さらにおそらくコンパイル時間は削減されますが)。しかしたとえそうだとしてもプラットフォームの機能に追従することは重要です。Java 8 のバイトコードをまだサポートしていないプラットフォームのためにJava 8のinvokedynamic命令をJava6用に書き換えるプロジェクトが2つ存在します(retrolambdaとForaxのJSR292のバックポート)。デフォルトメソッドに対する同様のプロジェクトの話は聞きませんが、おそらく可能でしょう。
Scala 2.11(要フラグ)と2.12で共通の機能
-
メソッドハンドルを利用した効率的なラムダのコンパイル。(2.11では互換用の個別のモジュールが必要です。下記参照。)
- Java 8との相互運用(双方向):
- Java 8バイトコードの読み込みサポートの改善(2.11に搭載済み)
- SAMサポートの改善とデフォルトでの有効化(Java 8スタイルの匿名クラスの合成)。これによりJava 8の高階メソッドをシームレスにScalaから呼び出せます(-Xexperimentalフラグを指定すれば2.11でも既に使用可能です)。
(訳注:SAM=Single Abstract Method メソッドを一つだけ持つインターフェース(Java 8のFunctionalInterface)のことを指すようです。)
- Java 8 からのScala高階メソッド呼び出しを可能にする互換用モジュール。
- Miguelの新しいバックエンドとオプティマイザの完全な統合(コードのリファクタリング、テストと詳細なドキュメント、古いバックエンドの削除)
- スタイルチェッカ:効率的で、コミュニティ主導の正しいコーディングスタイルチェック(コンパイラの最上位に組み込み)。
- コレクション:テストカバレッジ、パフォーマンス、ドキュメント(モジュール分割も?)の改善。
- 文書の改善:コンテンツに注力。(貢献するには絶好の場です。ツール関連のドキュメントに対しても。)
- 開発インフラの改善の継続(sbtビルド、プルリクエストの検証とリリース自動化の改善、バグトラッカのクリーンアップと自動化)。
Scala 2.12専用の機能:Java 8をもっと楽しむ
以下の機能の開発は2015年から開始します。これらはバイナリ非互換のため、2.11には導入しません。
- FunctionNをFunctionalInterfaceへ変換。これによってJava 8のコードはラッパなしにScalaの高階メソッドを呼べるようになります。
- @interfaceトレイトのサポート。これによりJavaのインターフェースへのコンパイルが保証されます(相互運用、パフォーマンス、バイナリ互換性に有効です)。上記の機能を一般化したものです。
- ストリーム:Scalaコレクションに統合する?(コンバータの提供から標準機能への変換に)
- 自前のfork-joinライブラリの代わりにJDKのライブラリを使う。(グローバルのデフォルトExecutionContextは、裏でForkJoinPool.commonPool()を使うように変わります。)
- SIP-20 lazy val 初期化処理の改善(時間が許せば)。
スケジュール
Scala 2.10.5 (2014年第4四半期)は2.10系列の最終リリースになります。2.11.xは2014年に5つのリリース、2015年にあといくつかを予定しています(2.11.xの最終リリースは検討中です)。2.12の開発は2014年の第4四半期にTypesafeでインフラの作業から開始されます。開発のフォーカスは2015年に2.12へと移ります。
2.10.0 2013/01/04 2.10.x 最初のリリース
2.11.0 2014/04/16 2.11.x 最初のリリース
2.11.1 2014/05/19
2.11.2 2014/07/21
2.11.3 2014/09/29
2.10.5 2014 第4四半期 2.10.x 最終リリース
2.12.0-M1 2014/11/24
2.11.4 2014 12月
2.12.0-M{2,3,4} 2015 第{1,2,3}四半期 2.12.0-Mx 3ヶ月おきのリリース
2.12.0-M5 2015 10月
2.12.0-RC1 2015 11月(M1の1年後)
2.12.0 2016 1月
2.11の開発中に、合計100万行に上るよく知られたオープンソースプロジェクト群のコミュニティビルドを通してリリースプロセスと回帰テストの自動化を大きく進歩させました。リリーススクリプトとコミュニティビルドは基本的に毎日最新のソースコードで実行されています。
上記のように、Scala2.11.1と同様バージョン2.x.yのy>0に対してはリリース候補を出さないことに決定しました。こうすることで決められたスケジュールにそってもっと頻繁にマイナーバージョンアップをリリースすることができるようになります。
(このロードマップは2014-06-30に公開されました。)