JDK 8から行われてきたクロスバージョンのラインマージは、JDK 9以降は廃止される予定です。
[]
開発者がJava Development Kit 8からJDK 9への移行を準備している矢先、Oracle Corporation***Javaの幹部は、2つのバージョン間でのコード行の併合を制限することを示唆しました。
月曜日の午後にOpenJDKに送られた電子メールの中で、オラクルのJavaプラットフォーム部門の***アーキテクトであるMark Reinhold氏は、JDK 8への変更はすぐに縮小され、JDK 9の "forests"--ディレクトリツリーまたはディレクトリセットのメカニズム--が間もなくオープンされる予定であることを指摘しました。-ディレクトリツリーやディレクトリセットのメカニズムの一種-が間もなく開放されます。開発者は現在、両方のバージョンでスムーズに作業するための管理上の変更に対処しなければならない、とラインホルド氏。
一般的に、変更はまず開発リリースでテストされ、それから以前のリリースに移行されます。しかし、開発終了リリースにはこのルールは当てはまりません。準備中のリリースはより本格的なテストとなり、後継リリースよりも新機能や特徴に焦点を当てることが少なくなるからです。また、調整が後継リリースに反映されるため、終了する前任者のリリースは遅くなります。
ここで、JDK 7では、Oracleは並行変更の処理に関するポリシーを提供していません。開発者は通常、要求に応じて現在のリリースに変更を組み込み、Sun/Oracle リリースエンジニアリングチームの担当者が半自動的な方法で前任者と後任者をマージします。異なる変更が正しいリリースに適用されていることを確認するために、脆弱性データベースのクエリーメカニズムが使用されます。
「このソリューションは、本来あるべき姿ではありませんでした。"何百人もの開発者が、前世代のバージョンを常に監視し、チューニングすることで、半自動マージプロセスが適切に機能しているかどうかを監視する必要がありました。" "マージが中止されるとすぐに、統合ワークフローに調整を加える必要がありました。"
先行リリースのリリースプロセスを合理化するために、ラインホルド氏はJDK 9の開発フォレストを、JDK 8の特定のビルドの初期状態から出発点として使用することを提案しています。"この一連のビルドの後では、両バージョンのコード行をマージすることはもはや許されません。JDK 8に変更をコミットした開発者は、その変更をJDK 9にも独自に提供する必要があります。
ラインホルド氏は、この動きによってプロセスがより合理化されることを期待しています。「私が考えられる唯一の欠点は、JDK 8 UniversalよりもJDK 8との互換性が優先されるため、開発者がJDK 9でJDK 8 Universalを作成できなくなることです。これができるようになれば便利でクールですが、実用的なレベルでの技術的価値というよりは、せいぜい達成感を得られる程度だと思います。人々はJDK 7のアップデートをJDK 8で作成することはできません。"状況は当時と今も変わりません。
Java Standard Edition 8をベースとするJDK 8は、Lambdaプロジェクトをサポートし、マルチコアプロセッサで動作するコードをより簡単に書くことができます。一連のプレビュー版はすでに利用可能。その後のバージョンであるJava SE 9は2016年初頭に利用可能になる見込みで、Jigsawプロジェクトを通じてJavaにモジュール機能をもたらします。
