原文はこちら。
https://eclipse-ee4j.github.io/jakartaee-platform/jakartaee9/JakartaEE9ReleasePlan
このエントリは2019/12/20現在の情報を基にしています。以後で原文に変更があった場合、追跡できないことがあるため、以下の内容とずれる可能性があります。
Scope
Jakarta EE 9の目標は、Jakarta EE 8と機能的に類似してはいるが、名前空間がjakarta.*に変わった一連の仕様を提供することである。
さらにJakarta EE 9では、Jakarta EE 8から古い仕様、オプショナルな仕様、もしくは廃止された仕様を除去する。これはAPIの表面積を減らし、新規ベンダーがエコシステムに参画しやすくするため、そして、これらの古いAPIの実装、移行、メンテナンスの負担を減らすためである。
プロジェクトチームはJakarta EE 9をツールリリースと見なしている。
- ツールベンダーが新しいjakarta.*という名前空間をサポートするツールを作成および更新できる、そのためのプラットフォーム
- 開発チームが、新しい名前空間へのアプリケーションの移行をテストするための安定した対象として使用できるプラットフォーム
- ランタイムベンダーが、移行およびJakarta EE 8との後方互換性をサポートするオプションと機能をテストおよび提供するために使用できるプラットフォーム
- Jakarta EE仕様プロジェクトがJakarta EE 10以降でリリースする新機能を推進するために使用できるイノベーションの基盤
Jakarta EE 9のスコープは、以下に示すJakarta EE Working Group Steering Committeeが可決したガイダンス決議を考慮に入れている。
(解決済み)Jakarta EE Steering Committeeは、Steering CommitteeでJakarta EE 9のロードマップとして採用することを検討するため、Jakarta EE Platform Projectのリーダーシップに対し、Jakarta EE 9 Delivery PlanをSteering Committeeに2019/12/9までに提示すること、そしてJakarta EE 9 Delivery Planには以下の制約を備えることを求めている。
- ビッグバンで実装すること
- 廃止もしくは削除対象の不要な仕様を特定し、廃止もしくは削除できるようにするための明示的な手段を含めること
- 残りのすべての仕様APIをJakarta名前空間に移動すること
- 適切な場合にはJava SE 8で削除された仕様を除き、原則として新規仕様を追加しないことを明示すること。ただし、(新規追加しようとしている)仕様がリリース予定日に明らかに影響を与えない場合を除く。
Namespace Changes
仕様をJakarta EE 9に含めるためには、APIパッケージ名をトップレベルのjavaxパッケージからトップレベルのjakartaパッケージに移行する必要がある。それ以外の変更は、Jakarta EE 9から削除された仕様を完全に削除するために必要な場合を除き、仕様で定義されたAPIに対して実施してはいけない。Jakarta EE 9から削除されたAPIをメソッドが参照している場合、メソッドを削除し、スキーマドキュメントを更新すべきである。このプロセスに対する例外処理には、個別のComponent Plan Reviewが必要である。
Specification Documents
Jakarta EE 9 Full ProfileもしくはWeb Profileのスコープ内に含まれる個々の仕様は、Eclipse Foundationが受け取った仕様文書をJakarta名前空間に変換し、別のJakarta仕様を参照し、これらの仕様文書をJakarta EE 9の一部としてリリースする必要がある。
Backwards Compatibility
Jakarta EE 9は、互換実装がJakarta EE 8をサポートする下位互換性の要件を課さない。これは、新しい実装がエコシステムに入ることを可能にするという私たちの目標と一致する。ただし、多くの製品とツールは、古いアプリケーションをJakarta EE 9で実行できるようにするための下位互換性と移行ソリューションを提供すると強く信じている。
Java SE Version
Jakarta EE 9に含めるには、仕様のAPIをJava SE 8ソースレベルでコンパイルする必要があるが、Jakarta EE 9 Web ProfileとFull Profileの互換実装は、Java SE 11における互換性を保証する必要がある。互換実装は、Java SE 8を追加で動作保証およびサポートしてよい。
Individual Specification Versioning
Jakarta EE名前空間の移動は重大な変更のため、Jakarta EE 9に含まれる全ての仕様は、仕様文書、API、その他の成果物の新しいメジャーバージョンをリリースしなければならない。例えば、仕様レベルでのセマンティックバージョン管理(JPA 2.x -> 3.0)、Mavenアーティファクトレベル、および仕様にとって適切な場合はパッケージレベル(OSGI)でのセマンティックバージョン管理(jakarta.persistenceであれば3.0)。
Specifications Included in Jakarta EE 9
以下ではJakarta EE 9 Full Profileに含まれる仕様を詳述する。
Updated in Jakarta EE 9
既存のJakarta EE 9の仕様は以下の通り。
- Jakarta Annotations
- Jakarta Concurrency
- Jakarta Messaging
- Jakarta Persistence
- Jakarta JSON Processing
- Jakarta Dependency Injection
- Jakarta Expression Language
- Jakarta Bean Validation
- Jakarta WebSocket
- Jakarta Servlet
- Jakarta Managed Beans
- Jakarta Mail
- Jakarta Authentication
- Jakarta JSON Binding
- Jakarta Server Pages
- Jakarta Debugging Support for Other Languages
- Jakarta Authorization
- Jakarta Interceptors
- Jakarta Contexts and Dependency Injection
- Jakarta Batch
- Jakarta RESTful Web Services
- Jakarta Transactions
- Jakarta Connectors
- Jakarta Standard Tag Library
- Jakarta Enterprise Beans
- Jakarta Security
- Jakarta Server Faces
- Jakarta EE 9 Full Platform
- Jakarta EE 9 Web Profile
Specifications Added to Jakarta EE 9
以前Java SE 8に含まれていた以下の仕様は、記載の通りRequiredもしくはOptionalの仕様としてJakarta EE 9に追加し、jakarta名前空間に移動する必要がある。
- Jakarta Activation (Required)
- Jakarta XML Binding (Optional)
- Jakarta XML Web Services (Optional)
- Jakarta Web Services Metadata (Optional)
- Jakarta SOAP with Attachments (Optional)
Specifications marked Optional in Jakarta EE 9
上記で追加され、optionalとしてマークされているものに加えて、Jakarta EE 9でoptionalとしてマークされている仕様は以下の通り。
- Jakarta Enterprise Beans 2.x API group
- Jakarta Enterprise Web Services, JSR 109
Specifications Pruned in Jakarta EE 9
Jakarta EE 9で削除される仕様は以下の通り。
- Jakarta Stable API Project Specifications
- Jakarta XML Registries
- Jakarta XML RPC
- Jakarta Deployment
- Jakarta Management
- EJB 3.2 Core SpecificationのChapter 10のDistributed Interoperabilityのサポート
Release Milestones
Jakarta EE 9プラットフォームプロジェクトは、このリリース計画がJakarta EE 9をターゲットにしている全ての仕様をカバーすることを提案している。 スコープに記載の通り、Jakarta EE 9に含めるための機能変更は行わないため、各仕様では個々の仕様リリース計画は不要ではあるものの、成果物が確実に存在するように、仕様ごとに最終Release Reviewを個別に実行することを提案している。
Waves
Jakarta EE 8で提供されたものと同様の仕組みで、Jakarta EE 9を提供することを提案している。これらのWaveは、仕様の依存関係ツリーにある程度関連している。最初に依存関係の数が少ない仕様を提供し、その後他の仕様が続くことを目指している。
Independent Wave (standalone)
以下の仕様は他のAPIと独立して提供してよい。
- Jakarta Annotations
- Jakarta Concurrency
- Jakarta Messaging
- Jakarta Persistence
- Jakarta Managed Beans
- Jakarta Web Services Metadata
Wave 1
Wave 1に含まれる仕様は以下の通り。
- Jakarta JSON Processing
- Jakarta Dependency Injection
- Jakarta Expression Language
- Jakarta Bean Validation
- Jakarta WebSocket
- Jakarta Servlet
- Jakarta Activation
- Jakarta SOAP with Attachments
- Jakarta Interceptors
Wave 2
Wave 2に含まれる仕様は以下の通り。
- Jakarta Mail
- Jakarta Authentication
- Jakarta JSON Binding
- Jakarta Server Pages
- Jakarta Debugging Support for Other Languages
- Jakarta Authorization
- Jakarta XML Binding
Wave 3
Wave 3に含まれる仕様は以下の通り。
- Jakarta Contexts and Dependency Injection
- Jakarta XML Web Services
Wave 4
Wave 4に含まれる仕様は以下の通り。
- Jakarta Batch
- Jakarta RESTful Web Services
- Jakarta Transactions
Wave 5
Wave 5に含まれる仕様は以下の通り。
- Jakarta Connectors
- Jakarta Standard Tag Library
- Jakarta Enterprise Beans
Wave 6
Wave 6に含まれる仕様は以下の通り。
- Jakarta Security
- Jakarta Server Faces
Wave 7
Wave 7に含まれる仕様は以下の通り。
- Jakarta EE 9 Full Platform
- Jakarta EE 9 Web Profile
Milestone Builds
Jakarta EE仕様プロジェクトは、依存プロジェクトが必要な名前空間の変更を進めることができるように、名前空間の変更とともにマイルストーンビルドとRCビルドをMaven Centralにできるだけ早く提供しなければならない。
Jakarta EE仕様プロジェクトは、JESP(Jakarta EE Specification Process)に準拠した後、完全なJakarta EE 9 Platformリリースの前に、仕様の完全なスタンドアロンリリースと最終化されたすべての成果物を作成できる。
計画の進捗はGitHubプロジェクトボードでEclipse EE4J組織レベルでトラッキングされる。各仕様のマイルストンはプロジェクトボードの列全体でトラッキングされる。
Full Profile and Web Profile Release Candidate
プロジェクトチームは、Wave 7の終了後にFull ProfileとWeb Profileの両方の1つ以上のリリース候補が提供されることを意図している。各Profileのリリース候補には以下が含まれている。
- Maven Centralに全てのAPIのJARファイルのリリース候補があること
- Maven CentralにFull Profile、Web Profileのリリース候補BOM(Bill of Material)pomファイルがあること
- リリース候補のTCK
- リリース候補の互換実装
リリース候補の目的は、完全なリリースの前にツールやユーザーが新しいAPIを試し、問題点や矛盾点を発見できるようにすることである。最初のリリース候補と最終リリースの間に2ヶ月の期間をおき、フィードバックを集め軽微な問題をリリース前に修正することを目指す。リリース候補を検証し、問題が解決されると、承認のためにSpecification Committeeに提出するために必要なすべての成果物を伴って完全なリリースの作業がスタートする。
Proposed Progress Reviews
プロジェクトチームはこのタイムラインがアグレッシブであり、これらの日付は早期の推定日であって、今後各リリースレビューにてレビューされ、調整されると見込んでいる。
- 個々のコンポーネントのプランレビュー (2月1日)
- 全てのAPIのJARが利用可能 (2月14日)
- Platform TCKの変更完了 (3月13日)
- Full ProfileとWeb Profileの最初のリリース候補 (5月4日)
- Full ProfileとWeb Profileの最終リリースレビュー投票の開始 (6月12日)
Compatible Implementation
JESPでは、Platform Projectが最終仕様を提供する前にFull ProfileとWeb Profileの互換実装が利用可能になることを求めている。この段階では、この実装はEclipse GlassFishであることが想定されている。しかし、PlatformプロジェクトはEclipse GlassFishのリリース日をコントロールできないため、Jakarta EE 9の開発期間中、Eclipse GlassFishプロジェクトと緊密に連携していく。