Blogsの主としてテクノロジー製品のエントリを日本語でご紹介します(オリジナルのエントリを投稿することもあります)。厳密性をご所望の方は原文をどうぞ。thanks!"でもいいので、是非コメントお願いします(Typoや誤訳はコメント欄からどうぞ)。このエントリは個人の見解であり、所属する会社の公式見解ではありません。エントリ内でご紹介している製品・サービスは国内導入時期が未定の場合もありますのでご了承下さい。Jigsawを延期することを提案しました。同時に、通常の2年間のリリースサイクルを今後のために明示的に目指すことを提案しました。以下はこうした提案に対する主要な質問とその回答をまとめたものです。いいえ、まだ決定していません。EGは、幅広くコミュニティから、関連するすべての入力を検討します。著名なブログやコラム、他の通信チャネルをお持ちなら、すでにあなたの意見を見ている可能性があります。SE8コメントリストに投稿してください。9に延期すべきという意見、その他の意見と、およそ均等に分かれていました。通常はあまり現実的でない選択肢が取られるのですが。Jigsawは、2008年8月にSunで始まりました。Sunの最後の年は、多くの場合と同様でスタッフが不足していました。Jigsawは当初一握りのほとんど非常勤エンジニアばかりで自転車操業していたので進歩は遅かったのです。SunがOracleに統合される間、Jigsawの全ての作業はしばらく中断しましたが、代替策の徹底した検討の後にプロジェクトは再開されました。Jigsawは約一年前に本当に十分なスタッフが配属されました。7が出荷された頃です。我々は、それ以来、チームに数人のエンジニアを追加しましたが、初期の頃の不十分な人員リソースと移行中に失われた時間を補うことができないでいます。本当に人員の制限や企業統合のごたごたの問題なのでしょうか。した難題はさておき、プロジェクトの遅延に関する他の主要な要因は、JDKのモジュール化に関する純粋に技術的な問題です。大きな理由が2個あります。JDKのコードベースが、APIと実装の両方のレベルで深く相互接続されているためです。それは主としてモノリシックなソフトウェアシステムのスタイルで長年にわたって構築されたためです。できるだけ多くのAPIや実装の依存性を排除したり、少なくともシンプルにして、プラットフォームおよびその実装の両方を相互に依存したモジュールの集約として提示できるように、膨大な労力を費やしてきましたが、特に厄介なケースが残っています。既存のクラスパスベースのアプリケーションだけでなく、実現可能な範囲内で、モジュールで構成されたアプリケーションのために、可能な限り、以前のリリースとの互換性を維持したいと考えているためです。JDKのモジュール化は必要なのでしょうか。SEプラットフォームのモジュール化により、標準の柔軟なJavaランタイム構成を大規模なサーバーから小型の組込み機器へスケールダウンできるようになります。SEの収束が可能になるでしょう。Jigsawは確かに主としてJDKのモジュール化に注力していましたが、プラットフォーム自体のためだけでなく、その上に構築されたライブラリやアプリケーションに対しても使えるということで、Javaプラットフォームのための真の標準モジュールシステムに対する需要が高まった結果、後でスコープが拡大することになりました。モジュール化されたJavaプラットフォームの導入により、長期的には、Javaの実装やライブラリ、フレームワーク、ツール、アプリケーションの設計、ビルド、デプロイ方式が根本的に変わるでしょう。モジュールシステムのコア機能の多くのプロトタイプを作成し、コンパイル時と実行時の両方で動作しています。モジュール宣言を使用してJavaプログラミング言語を拡張し、モジュラーソースツリーとそれに対応するコンパイルされたクラスツリーの構造を編み出して、これらの機能をjavacに実装しました。効率的なモジュール・ファイル・フォーマットを定義し、モジュラーJREを起動するようJVMを拡張し、予備的なAPIを設計、実装してきました。APIを意味のあるモジュールの集合体に分割する上での最初の切り込みを入れました。APIを改造して、モジュラーサービスをサポートするようにしています。プロジェクトのページで、要件のドラフトと設計概要の文書をお読み下さい。最新のプロトタイプビルドをダウンロードし実行して下さい。あなたの考えを教えて下さい。jigsaw-devのメーリングリストで、リアルタイムに現在の残りの作業を追うことができます。Jigsawには2フェーズあります。第1フェーズではこれまでのJavaのモジュール方式のソリューションとは著しく異なるモジュール方式を模索しています。我々は、Javaプログラミング言語、仮想マシン、およびAPIの変更が可能と仮定しました。することで、コンパイルから、デプロイ、実行まで、すべてのプログラムの段階でモジュールの境界を強く強制できる設計が可能になります。これは、順番に、使い勝手、診断のしやすさ、セキュリティ、およびパフォーマンスの向上につながります。EGの成果を知らせることができるプロトタイプを生成することです。EGが作成する仕様の参照実装を作成する予定です。EGは、現在模索しているものとは全く異なるアプローチを最終的に選択する場合があります。Jigsawは必要に応じて筋道が変わる可能性がありますが、いずれにせよ最終的な結果はいいものになるでしょう。Mavenはプロジェクト管理ソフトウェアで包括的なツールです。ビルド時のモジュールシステムであって、実行時のモジュールをサポートしないからです。OSGiは、リッチな動的コンポーネントシステムで、モジュール化されたシステムだけでなく、ライフサイクルモデルと動的なサービスレジストリを含んでいます。SEプラットフォームの標準化にそれほど関心がないように思われるからです。OSGiのモジュール層は、コンパイル時には動作せず、パッケージング、デプロイ、実行時のモジュール化にのみ対応しています。SEプラットフォームの上に構築されているので、プラットフォーム自体をモジュール化するために使用できません。Mavenがビルド時にモジュールに対応し、OSGiモジュール層がデプロイ、実行時にモジュールに対応するのであれば、なぜ両者を組み合わせて利用しないの?多くの開発者が既にやっているでしょ。MavenとOSGiの組み合わせは、現時点では確かに非常に便利です。これらのシステムは、既存のJavaプラットフォーム上に構築されています。プラットフォーム自体を変更できなかったのです。これは、とりわけモジュールの境界が弱いことを意味しており、それゆえ構成エラーの診断が難しく、信頼できないコードを安全に実行できなくなっています。対照的に、プロトタイプのJigsawモジュールシステムは、プラットフォームレベルのソリューションを定義することを目的としており、言語とJVMの両方を拡張して、全てのプログラムフェーズで均一にモジュールの境界を強固にしようとしています。そんなことはありません。どんアプローチを採用したとしても、広範囲に採用されるためには、標準のJavaプラットフォームモジュールシステムがMavenとうまく連係することが不可欠です。OSGiの洗練された機能に依存するアプリケーションは今後もOSGiを使い続けることは確実で、それゆえOSGiの実装がJavaモジュールシステム上で動作できること、もし適切に修正された場合にはJavaモジュールに依存するOSGiバンドルをサポートできることが重要です。Penroseで検討しています。308)、その他現在進行中の小さな機能を含めることなどが計画されています。確かに収束が遅くなるでしょうが、止まることはないでしょう。8が出荷された後に再びJigsawの作業に戻ることになるのでしょうか。9の出荷までJigsawをメインに担当します。8の主要機能の開発に残された時間は9ヶ月もありません。したJavaプラットフォームへの根本的な変更が必要な広範なレビューやテスト、フィードバックのための時間はありません。8でモジュールシステムを出荷しないのでしょう。9でプラットフォームのモジュール化がなされるのでしょうか。あるリリースでモジュールシステムを提供しても、あるリリースまでそのモジュールシステムを使ってJDKをモジュール化しない場合、根本的に勘違いする大きなリスクを冒すことになります。なった場合、後のリリースで修正する必要があり、根本的な設計上の問題を修正した結果、ほぼ確実に粗悪な結果につながります。8リリース後2年以内にJigsawを出荷するというのはどうでしょう。今日、数年前よりもずっと多くの開発者がJDKに携わっていますが、それはOracleの投資が劇的に増加したこと、そして他の企業や個人がOpenJDKコミュニティに参加したことが理由です。リリースに必要な余力がないため、およそ2年ごとよりも頻度を多く、JDKのメジャーリリースの長期にわたるサポートを提供することはできません。新機能が早く利用できるよう、より頻繁にリリースすべきというコメントもあれば、ミッションクリティカルなアプリケーションをリリースする企業開発者の大規模チームが快適なペースで移行できるよう、リリースサイクルが遅くしてほしい、という問い合わせもあります。