[Java] Project Jigsaw: Late for the train: The Q&A

原文はこちら。
http://mreinhold.org/blog/late-for-the-train-qa

---

最近、一般のJavaコミュニティと、特にJava SE 8（JSR337）専門家グループに対し、Java 8からJava 9へProject Jigsawを延期することを提案しました。と同時に、通常の2年間のリリースサイクルを今後のために明示的に目指すことを提案しました。
以下はこうした提案に対する主要な質問とその回答をまとめたものです。

Project Jigsaw: Late for the train
http://mreinhold.org/blog/late-for-the-train
Java SE 8 Platform Umbrella JSR (337)
http://openjdk.java.net/projects/jdk8/spec/
Modularity in Java SE 8
mail.openjdk.java.net/pipermail/java-se-8-spec-observers/2012-July/000001.html
Project Jigsaw
http://openjdk.java.net/projects/jigsaw/

Making the decision

質問	回答
Java Se 8専門家グループ（EG)はモジュールシステムの追加とプラットフォームのモジュール化をJava SE 9に引き延ばすか否かを決定したのですか？	いいえ、まだ決定していません。
いつまでにEGにこの決定をしてもらいたいですか？	来月中ぐらいには。
自分の提案がどのように反映されているか確認するにはどうすればいいでしょう？	EGは、幅広くコミュニティから、関連するすべての入力を検討します。著名なブログやコラム、他の通信チャネルをお持ちなら、すでにあなたの意見を見ている可能性があります。そうでない場合は、EGの公式フィードバックチャネルであるJava SE8コメントリストに投稿してください。
受けとったフィードバックの全体的なトーンはどのようなものですか？	フィードバックは、Java 8をJigsawのために遅らせるべきという意見と、JigsawをJava 9に延期すべきという意見、その他の意見と、およそ均等に分かれていました。通常はあまり現実的でない選択肢が取られるのですが。

Project Jigsaw

質問	回答
Project Jigsawに時間がかかっている理由は？	Project Jigsawは、2008年8月にSunで始まりました。Sunの最後の年は、多くの場合と同様でスタッフが不足していました。Jigsawは当初一握りのほとんど非常勤エンジニアばかりで自転車操業していたので進歩は遅かったのです。SunがOracleに統合される間、Jigsawの全ての作業はしばらく中断しましたが、代替策の徹底した検討の後にプロジェクトは再開されました。Project Jigsawは約一年前に本当に十分なスタッフが配属されました。Java 7が出荷された頃です。我々は、それ以来、チームに数人のエンジニアを追加しましたが、初期の頃の不十分な人員リソースと移行中に失われた時間を補うことができないでいます。
では、本当に人員の制限や企業統合のごたごたの問題なのでしょうか。	こうした難題はさておき、プロジェクトの遅延に関する他の主要な要因は、JDKのモジュール化に関する純粋に技術的な問題です。
JDKのモジュール化がそんなに大変なのはなぜですか？	大きな理由が2個あります。まず、JDKのコードベースが、APIと実装の両方のレベルで深く相互接続されているためです。それは主としてモノリシックなソフトウェアシステムのスタイルで長年にわたって構築されたためです。できるだけ多くのAPIや実装の依存性を排除したり、少なくともシンプルにして、プラットフォームおよびその実装の両方を相互に依存したモジュールの集約として提示できるように、膨大な労力を費やしてきましたが、特に厄介なケースが残っています。
2番目の理由は？	既存のクラスパスベースのアプリケーションだけでなく、実現可能な範囲内で、モジュールで構成されたアプリケーションのために、可能な限り、以前のリリースとの互換性を維持したいと考えているためです。
JDKのモジュール化は必要なのでしょうか。大きなモジュールにまとめてしまえないんですかね？	JDKのモジュール化、より具体的にはJava SEプラットフォームのモジュール化により、標準の柔軟なJavaランタイム構成を大規模なサーバーから小型の組込み機器へスケールダウンできるようになります。長期的にはハイエンドのJava MEプラットフォームとJava SEの収束が可能になるでしょう。
Project Jigsawとは単にJDKをモジュール化するだけなのですか？	元々の認識では、Project Jigsawは確かに主としてJDKのモジュール化に注力していましたが、プラットフォーム自体のためだけでなく、その上に構築されたライブラリやアプリケーションに対しても使えるということで、Javaプラットフォームのための真の標準モジュールシステムに対する需要が高まった結果、後でスコープが拡大することになりました。
開発者がProject Jigsawに注目すべき理由は？	モジュール化されたJavaプラットフォームの導入により、長期的には、Javaの実装やライブラリ、フレームワーク、ツール、アプリケーションの設計、ビルド、デプロイ方式が根本的に変わるでしょう。
これまでのProject Jigsawの進捗は？	着実に進んでいます。モジュールシステムのコア機能の多くのプロトタイプを作成し、コンパイル時と実行時の両方で動作しています。モジュール宣言を使用してJavaプログラミング言語を拡張し、モジュラーソースツリーとそれに対応するコンパイルされたクラスツリーの構造を編み出して、これらの機能をjavacに実装しました。 効率的なモジュール・ファイル・フォーマットを定義し、モジュラーJREを起動するようJVMを拡張し、予備的なAPIを設計、実装してきました。モジュールシステムを使ってJDKとJava SE APIを意味のあるモジュールの集合体に分割する上での最初の切り込みを入れました。特に現在、ためにjava.util.ServiceLoader APIを改造して、モジュラーサービスをサポートするようにしています。
お手伝いしたいんですが、どうすればいいですか？	プロジェクトのページで、要件のドラフトと設計概要の文書をお読み下さい。最新のプロトタイプビルドをダウンロードし実行して下さい。あなたの考えを教えて下さい。jigsaw-devのメーリングリストで、リアルタイムに現在の残りの作業を追うことができます。

The Java Platform Module System JSR

質問	回答
Project Jigsawと最終的なJavaプラットフォームモジュールシステムのJSRとの関係は？	ハイレベルで見ると、Project Jigsawには2フェーズあります。第1フェーズではこれまでのJavaのモジュール方式のソリューションとは著しく異なるモジュール方式を模索しています。 我々は、Javaプログラミング言語、仮想マシン、およびAPIの変更が可能と仮定しました。そうすることで、コンパイルから、デプロイ、実行まで、すべてのプログラムの段階でモジュールの境界を強く強制できる設計が可能になります。これは、順番に、使い勝手、診断のしやすさ、セキュリティ、およびパフォーマンスの向上につながります。第1フェーズの究極の目標は、モジュールシステムJSR EGの成果を知らせることができるプロトタイプを生成することです。
Project Jigsawの第2フェーズではどうなるの？	第二フェーズでは、モジュールシステムJSR EGが作成する仕様の参照実装を作成する予定です。 EGは、現在模索しているものとは全く異なるアプローチを最終的に選択する場合があります。その場合、Project Jigsawは必要に応じて筋道が変わる可能性がありますが、いずれにせよ最終的な結果はいいものになるでしょう。

Maven & OSGi

質問	回答
なぜMavenを使わないの？	Mavenはプロジェクト管理ソフトウェアで包括的なツールです。ビルド時のモジュールシステムであって、実行時のモジュールをサポートしないからです。
なぜOSGiを採用しないの？	OSGiは、リッチな動的コンポーネントシステムで、モジュール化されたシステムだけでなく、ライフサイクルモデルと動的なサービスレジストリを含んでいます。後者の二つのファシリティは、ある種の高度なアプリケーションにとって有用ですが、これらがJava SEプラットフォームの標準化にそれほど関心がないように思われるからです。
じゃあ、なぜOSGiのモジュールレイヤを採用しないの？	OSGiのモジュール層は、コンパイル時には動作せず、パッケージング、デプロイ、実行時のモジュール化にのみ対応しています。さらに、現状では、ライブラリとアプリケーション·モジュールには有用ですが、厳密にはJava SEプラットフォームの上に構築されているので、プラットフォーム自体をモジュール化するために使用できません。
If Mavenがビルド時にモジュールに対応し、OSGiモジュール層がデプロイ、実行時にモジュールに対応するのであれば、なぜ両者を組み合わせて利用しないの？多くの開発者が既にやっているでしょ。	MavenとOSGiの組み合わせは、現時点では確かに非常に便利です。しかし、これらのシステムは、既存のJavaプラットフォーム上に構築されています。つまりプラットフォーム自体を変更できなかったのです。これは、とりわけモジュールの境界が弱いことを意味しており、それゆえ構成エラーの診断が難しく、信頼できないコードを安全に実行できなくなっています。対照的に、プロトタイプのJigsawモジュールシステムは、プラットフォームレベルのソリューションを定義することを目的としており、言語とJVMの両方を拡張して、全てのプログラムフェーズで均一にモジュールの境界を強固にしようとしています。
EGが現在のJigsawのプロトタイプのようなアプローチを選択した場合、MavenとOSGiは廃止されるの？	そんなことはありません。どんアプローチを採用したとしても、広範囲に採用されるためには、標準のJavaプラットフォームモジュールシステムがMavenとうまく連係することが不可欠です。OSGiの洗練された機能に依存するアプリケーションは今後もOSGiを使い続けることは確実で、それゆえOSGiの実装がJavaモジュールシステム上で動作できること、もし適切に修正された場合にはJavaモジュールに依存するOSGiバンドルをサポートできることが重要です。これを実現するためのアイデアを現在Project Penroseで検討しています。

Java 8 & Java 9

質問	回答
Jigsawがないと、Java 8はつまらないリリースになるんじゃないの？	いいえ、とんでもない！待望のProject Lambda（JSR 335）、新しいDate/Time API（JSR 310）、Type Annotation（JSR 308）、その他現在進行中の小さな機能を含めることなどが計画されています。
JigsawをJava 9に延期したら、Java SEとハイエンドのJava MEプラットフォームの収束が結果として遅れないの？	確かに収束が遅くなるでしょうが、止まることはないでしょう。その収束に向けて進展がJava 8でなされるために、SEプラットフォームのコンパクトな構成を構築、デプロイできる少数のProfileを指定することを検討すべきとJava SE 8 EGに提案しました。
JigsawをJava 9に延期した場合、現在Jigsawに携わっているOracleのエンジニアは、他のJava8の機能に再割り当てされ、Java 8が出荷された後に再びJigsawの作業に戻ることになるのでしょうか。	いいえ、現在携わっているエンジニアはJava 9の出荷までJigsawをメインに担当します。
LambdaをやめてJigsawを完成させなかったのはなぜ？	現在Lambdaに携わるエンジニアが即座Jigsawに切り替わりすぐに開発の力になる可能性があったとしても（もちろんそんなことはないのですが）、Java 8の主要機能の開発に残された時間は9ヶ月もありません。こうしたJavaプラットフォームへの根本的な変更が必要な広範なレビューやテスト、フィードバックのための時間はありません。
なぜJava 8でモジュールシステムを出荷しないのでしょう。そして、Java 9でプラットフォームのモジュール化がなされるのでしょうか。	あるリリースでモジュールシステムを提供しても、あるリリースまでそのモジュールシステムを使ってJDKをモジュール化しない場合、根本的に勘違いする大きなリスクを冒すことになります。そうなった場合、後のリリースで修正する必要があり、根本的な設計上の問題を修正した結果、ほぼ確実に粗悪な結果につながります。
8.5リリース、つまりJava 8リリース後2年以内にJigsawを出荷するというのはどうでしょう。隔年ではなく、毎年新リリースを出すというのはどうですか？	今日、数年前よりもずっと多くの開発者がJDKに携わっていますが、それはOracleの投資が劇的に増加したこと、そして他の企業や個人がOpenJDKコミュニティに参加したことが理由です。しかし、総じて、リリースに必要な余力がないため、およそ2年ごとよりも頻度を多く、JDKのメジャーリリースの長期にわたるサポートを提供することはできません。
2年のリリースサイクルの提案に対するフィードバックは？	新機能が早く利用できるよう、より頻繁にリリースすべきというコメントもあれば、ミッションクリティカルなアプリケーションをリリースする企業開発者の大規模チームが快適なペースで移行できるよう、リリースサイクルが遅くしてほしい、という問い合わせもあります。