Home on Jakarta® EE: クラウドネイティブJavaの新ホーム

Change Log

webdev@eclipse-foundation.org (Eclipse Foundation) — Fri, 29 May 2026 00:00:00 +0000

Release for Jakarta EE 10

Jakarta EE 12

webdev@eclipse-foundation.org (Eclipse Foundation) — Thu, 26 Feb 2026 00:00:00 +0000

Jakarta EE 12 focuses on robust and flexible enterprise Java, supporting reliable applications while enabling modularity, interoperability, and architectural choice.

This page will be updated regularly to reflect new proposals, milestones, and specification work as they become available.

Updated

Not Updated

New

* Candidate for inclusion.

Change Log

webdev@eclipse-foundation.org (Eclipse Foundation) — Fri, 12 Apr 2024 00:00:00 +0000

Batch 2.1 Change Log

Change Log

webdev@eclipse-foundation.org (Eclipse Foundation) — Thu, 11 May 2023 00:00:00 +0000

Release for Jakarta EE 10

Change Log

webdev@eclipse-foundation.org (Eclipse Foundation) — Fri, 05 May 2023 00:00:00 +0000

Release for Jakarta EE 10

Change Log

webdev@eclipse-foundation.org (Eclipse Foundation) — Sat, 29 Apr 2023 00:00:00 +0000

Release for Jakarta EE 10

Change Log

webdev@eclipse-foundation.org (Eclipse Foundation) — Sat, 29 Apr 2023 00:00:00 +0000

Release for Jakarta EE 10

Change Log

webdev@eclipse-foundation.org (Eclipse Foundation) — Sat, 29 Apr 2023 00:00:00 +0000

Release for Jakarta EE 10

Change Log

webdev@eclipse-foundation.org (Eclipse Foundation) — Sat, 29 Apr 2023 00:00:00 +0000

Release for Jakarta EE 10

Jakarta EEを使用する理由

webdev@eclipse-foundation.org (Eclipse Foundation) — Thu, 20 Oct 2022 14:49:08 -0400

JAKARTA EE IS CONTINUATION

Javaは業界で広く普及しているプログラミング言語の1つであり、安定性、互換性、および移植性に関して比類のない評判を得ています。Javaの台頭とともに、Java EEはエンタープライズJavaアプリケーション開発のための一連の仕様として確立されました。Java EEは、この10年間でアプリケーション開発者の主要な技術になりました。Fortune 500企業の大半がミッションクリティカルアプリケーションをJava EEで、そして現在ではJakarta EEで走行しています。アプリケーション開発技術に対するオープンでベンダー中立、コミュニティ主導のアプローチを選択しています。

Jakarta EE仕様プロセス

webdev@eclipse-foundation.org (Eclipse Foundation) — Wed, 31 Aug 2022 13:00:00 -0400

バージョン1.4 2022年8月31日発効

Jakarta EE仕様プロセス(JESP)は、Jakarta EEワーキンググループの下で運営されている仕様プロジェクトに適用される仕様プロセスに関係しています。

Jakarta EE仕様委員会は、以下の修正を加え、Eclipse Foundation仕様プロセス v1.3 (EFSP)をJakarta EE仕様プロセスとして採用します。

1.EFSPの新しいバージョンの採択を含む、このJakarta EE仕様プロセスの修正または改訂は、EFSPに定められたその他の投票要件に加えて、Jakarta EEワーキンググループのStrategicメンバーの圧倒的多数を含む仕様策定委員会の過半数の承認を得る必要があります。 2.すべての仕様策定委員会の承認投票期間には、次に示す期間が設定されます（EFSPによって定義された例外プロセスにかかわらず） a.Creationレビュー：7暦日、 b.Planレビュー:7暦日、 c.Progressレビュー:14暦日、 d.Releaseレビュー:14暦日、 e.Service Releaseレビュー：14暦日、 f.JESPの更新：7暦日。 3.7日間の投票は、7日後に終了します。14日間の投票は、次のいずれかが発生した時点で終了します。 a.少なくとも7日が経過し、すべての適格なメンバーが投票した。 b.14日間の投票期間が終了した。

4.仕様チームが該当レビューを取り下げた場合、投票は無効とされ、直ちに終了します。 5.仕様プロジェクトは、開発が継続している間、少なくとも1年に1回のProgressレビューまたはReleaseレビューを実施する必要があります。

「javax」名前空間内のコンテンツを変更するすべての開発は、「jakarta」名前空間に移動する必要があります。すべての「jakarta」名前空間のデプロイメントは、Jakarta EEワーキンググループの仕様委員会の下で運営されている仕様プロジェクトの範囲内で行われなければならず、JESPの最新の改訂によって定義されたプロセスを実施しなければなりません。「jakarta」名前空間の使用は、APIアーティファクト(すべてのAPI jar、javadoc、およびスキーマ名前空間)に制限されます。アプリケーション、TCK、ツール、ライブラリ、その他仕様プロジェクトによって作成されたものを含む、いかなるデプロイメントにも使用してはなりません。

EFSPは、このドキュメントで言及されていない場合に優先されます。EFSPの優位性にかかわらず、このドキュメントは、Jakarta EEワーキンググループの範囲内で仕様プロジェクトが実施する仕様開発に関するすべての事項において優先されます。

javaxからjakarta名前空間に関するエコシステムの進捗状況

martijn@londonjavacommunity.co.uk (Martijn Verburg) — Wed, 31 Aug 2022 09:00:00 +0000

Jakarta EEエコシステムは、さまざまなライブラリ、フレームワーク、サーバ、ツールをjavax名前空間からjakarta.ee名前空間に移行することに尽力してきました。この作業は、Jakarta EE 10の今後のリリースで本質的に完了します。JakartaEEの開発者は、各カテゴリーに幅広い選択肢があり、優れた選択肢を提供します。

Change Log

webdev@eclipse-foundation.org (Eclipse Foundation) — Wed, 15 Jun 2022 00:00:00 +0000

Release for Jakarta EE 9

2022年Jakarta EE開発者アンケートが開始されました！

shabnam.mayel@eclipse-foundation.org (Shabnam Mayel) — Mon, 21 Mar 2022 19:00:00 +0000

2022年Jakarta EE開発者アンケートの所要時間は、6分未満です。しかしながら、皆さんのご意見は非常に重要です。

クラウドネイティブJavaの未来を形作る

webdev@eclipse-foundation.org (Eclipse Foundation) — Fri, 04 Mar 2022 09:00:00 -0400

Jakarta EEに参加しよう！

Jakarta EEプロジェクトやイニシアチブに参加するには、まずEclipse Foundationアカウントを作成します。

アカウントを取得したら、以下のいずれかの方法で参加できます。

会話に参加する

最新のコミュニティの取り組みについて学び、参加する方法を決めるために、ミュニケーションチャネルに参加してください。

ソーシャルメディアに参加する

貢献の方法

興味のあるJakarta EEプロジェクトを選び、プロジェクトのメーリングリストに参加してチームとコミュニケーションを取りましょう。

貢献を開始する前に、事務手続きが正しく行われていることを確認する必要があります。個人で貢献する場合は、EFアカウントにログインし、Eclipse Contributor Agreementに署名してください。その後、プロジェクトチームと協力して作業を行うことができます。契約の詳細については、Eclipse Contributor Agreementページを参照してください。ただし、雇用主がすでにJakarta EEワーキンググループメンバーである場合、雇用主は貢献している従業員すべてをカバーするメンバーコミッタ寄稿同意書があるため、何もする必要はありません。

EFアカウントにログインします

コミッターになる

Jakarta EE貢献者はコミッターになる資格があります。コミッターになるには、いくつかの方法があります。1) 既存のJakarta EEプロジェクトの場合、投票により選出されます。該当オープンソースプロジェクトがどのように機能するか理解していることを示す貢献を行った後、そのプロジェクトの現在のコミッターの一人が投票を開始します。現在のコミッターはそれに投票しなければなりません。そのため、コミッター（およびコミュニティ）がレビューできる質の高い貢献を公に積み重ねることが、このプロセス全体の中で最も重要な部分です。2) もう一つの選択肢は、初期貢献をすることで、新しいJakarta EE仕様プロジェクトのコミッターになることです。プロジェクトの対応するプロジェクト管理委員会（PMC）は、エグゼクティブディレクター（またはその代理）に承認をえるための初期コミッターを指名します。

雇用主がJakarta EEワーキンググループメンバーである場合、雇用主はすでに必要な書類に署名しており、あなたが用意する書類はありません。

雇用主がJakarta EEワーキンググループのメンバーでない場合は、次のフォームに記入する必要があります。

コミッターの役割とEclipse Foundationの開発プロセスの詳細については、Eclipse Foundationプロジェクトハンドブックを参照してください。

Jakarta EE TCK Process 1.3

webdev@eclipse-foundation.org (Eclipse Foundation) — Mon, 07 Feb 2022 00:00:00 +0000

Eclipse Foundation仕様プロセスにおける仕様プロジェクトは、複数の互換実装を可能にするという目的を実現するためにTechnology Compatibility Kit（TCK）を作成する必要があります。

このドキュメントでは、次の事項を定義します。

移植性の実現のために適切と考えられる、TCKが提供しなければならない資料
最終TCKの承認
テストに対する異議申し立てプロセスとその解決方法
リリース済みのTCKテストを認証要件から除外する方法
リリース済み仕様に対するTCKテストの改善方針
自己認証手続
TCK異議申し立てを解決するための（TCKの）サービスリリース（x.y.z）のプロセス

役割と制限

TCKの役割は、実装の互換性とアプリケーションの移植性の両方を確保することです。

TCKテストは、仕様の規定、商標ガイドライン、ライセンス条項を含むがこれに限定されない、アプリケーションが遵守すべきすべてのルールおよび制限事項に従って記述される必要があります。アプリケーションに関するこれらの規則および制限に従わないテストは無効とみなされ、異議申し立てプロセスで除外される場合があります。

名前空間

TCKテストは jakarta.* 名前空間にパッケージ化しないでください。現時点では、TCKは他の名前空間にパッケージされていても構いませんが、名前空間の形式は ee.jakarta.tck.<spec-name> が推奨されます。

TCKリリースの資料

アーティファクト:

プロジェクトは、Maven Centralまたは他のオープンソースチャンネルに配布するためのプロジェクトライセンス（EPL、Apacheなど）バージョンを作成し、自動化された非公式テストと実装に使用可能である必要があります。このTCKをもとに互換性を主張することはできません。
プロジェクトは、 EFTLライセンスを含む最終候補バイナリを作成する必要があります。Jakarta EE仕様策定委員会は、最終承認後、Eclipseインフラを通じて配布するために、プロジェクトTCKバイナリを署名してプロモートします。これは、互換性を主張したい場合に自己認証に使えるTCKバイナリで、Jakarta ブランドの使用を許可するものです。
両方のTCKバイナリには、以下が含まれる必要があります
- ユーザーガイドのアウトライン
  - ソフトウェア要件
  - インストールと構成
  - テストの実行方法
  - 異議申し立てする場所
  - このプロセスガイドでカバーされていないTCK固有の規則
- TCKの検証に使用される互換実装の実行方法を記載した説明書
- 上述の各ドキュメントを指し示すトップレベルのREADMEドキュメント
TCKのドキュメントには次の項目を含めることを推奨します
- 認証申請、バグレポート等のイシュートラッカーのURL
- 互換性を主張する前に、互換性認証プロセスに従わなければならないことを示す文。
TCKバイナリは、以下を含むことができます。
- テストカバレッジ文書
- テストアサーション文書
プロジェクトのGitHubリリースページ(または同等ページ)から利用可能なリリース
- EFTL下の最終リリースは、次の場所でホストされる必要があります: download.eclipse.org

最終TCKの承認

プロジェクトは、EFTL版TCKの最終バイナリ案を仕様策定委員会の承認のために提出します。

Change Log

webdev@eclipse-foundation.org (Eclipse Foundation) — Fri, 26 Mar 2021 00:00:00 +0000

Release for Jakarta EE 9

Change Log

webdev@eclipse-foundation.org (Eclipse Foundation) — Sun, 21 Mar 2021 00:00:00 +0000

Release for Jakarta EE 9

Change Log

webdev@eclipse-foundation.org (Eclipse Foundation) — Sun, 21 Mar 2021 00:00:00 +0000

Release for Jakarta EE 9

Change Log

webdev@eclipse-foundation.org (Eclipse Foundation) — Sun, 21 Mar 2021 00:00:00 +0000

Release for Jakarta EE 9

Change Log

webdev@eclipse-foundation.org (Eclipse Foundation) — Sun, 21 Mar 2021 00:00:00 +0000

Release for Jakarta EE 9

Change Log

webdev@eclipse-foundation.org (Eclipse Foundation) — Wed, 17 Mar 2021 00:00:00 +0000

Release for Jakarta EE 9

Jakarta EE互換実装と互換製品

webdev@eclipse-foundation.org (Eclipse Foundation) — Thu, 11 Mar 2021 00:00:00 +0000

Jakarta EEは、エンタープライズJavaアプリケーション開発に使用されるオープンな仕様のセットです。これは、Java EE技術の後継で、将来のクラウドネイティブJavaエンタープライズアプリケーションの仕様を前進させることに興味を持つJava開発者が集まった幅広いコミュニティです。各仕様リリースには、関連するTechnology Compatibility Kit（TCK）が含まれます。TCKへのリンクは、該当する仕様リリースページにあります。例えば、Jakarta EE Platform 9.0、または、コンポーネント仕様の場合は、Jakarta Authentication 2.0を参照してください。

Jakarta EEワーキンググループでは、コンポーネント仕様のすべての互換実装に焦点を当てることができます。さらに、Jakarta EEワーキンググループは、Jakarta EEプラットフォームまたはJakarta EE Webプロファイル仕様の互換実装である互換製品に焦点を当てています。

実装をJakarta EE互換として指定する際の最初のステップは、対応する仕様との互換性を実証するために、各TCKに対応する適切な仕様をパスし、Eclipse Foundation Technology Compatibility Kit Licenseの利用規約に準拠していることを確認することです。これは、実装者が、TCKのマニュアルに記載されている要件、特にTCKユーザーガイドに記載されている要件を含め、各仕様のすべての互換性要件を確認していることを前提としています。

TCKが成功裏に通過したら、次のステップは、それを世界に知らせることです。つまり、次の項目を実施します。

GitHubのイシューを提出して仕様プロジェクトチームに通知し、承認を得て、
PRを作成して、Jakarta EEワーキンググループが適切な仕様ページに互換実装をリストできるよう支援します。互換製品の場合は、Jakarta EEプラットフォーム仕様および/またはJakarta EE Webプロファイル仕様の実装が互換製品ページに掲載されます。

Jakarta EEワーキンググループへのメンバーシップを含む、追加の必要な手順があります。互換製品ページに掲載されている製品は、Jakarta EE商標ガイドラインに従い、Jakarta EE互換ロゴを使用することができます。

Jakarta EEコンポーネント仕様の互換実装としてリストされる方法

個々のJakarta EEコンポーネントの仕様ページで、あなたの実装を互換実装ページとして表示するには、次の手順に従います。

Jakarta EE TCKプロセスに従って、該当するTCKテストのすべての要件を完全に満たして実行し、Eclipse Foundation TCKライセンスに準拠します
- 仕様の互換性を主張し続ける限り、TCKの結果を公開し、TCKの結果の公開リストを維持してください。
- TCKの結果をtck@eclipse.orgにメールで送信します。
GitHubリポジトリの仕様プロジェクトに認証リクエストイシューを提出します
Jakarta EE仕様リポジトリに対してGitHubプルリクエスト（PR）を開き、必要な情報を入力します

Jakarta EEプラットフォームまたはJakarta EE Webプロファイルの互換製品として掲載される方法

あなたの製品を互換製品ページに表示し、Jakarta EE互換ロゴを使用できるようにするには、次の手順に従います。

ブランドと互換ロゴの要件
- Jakarta EEワーキンググループに参加します
- Jakarta EE商標ガイドラインを参照します。
- Jakarta EE Compatibility Trademark License Agreementを実行（デジタル署名）します（またはLicense Agreement PDFを印刷し、署名した契約書をemo-records@eclipse.orgに返送します）
互換認証とjakarta.eeの互換製品ページ掲載の要件
- Jakarta EE TCKプロセスに従って、該当するTCKテストのすべての要件を完全に満たし、実行します
  - 互換性を主張し続ける限り、TCKの結果を公開し、TCKの結果の公開リストを維持します。
  - TCKの結果をtck@eclipse.orgにメールで送信します。
- GitHubリポジトリに仕様プロジェクトを含む認証リクエストを提出します。
- GitHubイシューを開き、Jakarta EE互換製品リポジトリに対して必要な情報を入力します

Jakarta EE仕様プロセスガイド

webdev@eclipse-foundation.org (Eclipse Foundation) — Thu, 04 Mar 2021 00:00:00 +0000

Content

はじめに

このガイドは、Jakarta EE仕様プロセスの開発者がJakarta EE仕様プロセス（JESP）のステップをナビゲートするのに役立つステップバイステップの実用的なガイドです。

便利ツールとして提供するものですので、疑問がある場合は、必ずJESPを参照してください。 Jakarta EE仕様の開発に関するご質問・ご意見等ございましたら、仕様委員会まで、お気軽にお問い合わせください。JESPは、Eclipse仕様プロセス（EFSP）を採用しています。

This diagram is the Eclipse Specification Version Lifecycle. It shows the steps to create and evolve a Specification.

The most important kind of step in the lifecycle is the Review step. A Review is an event that takes place over a week or two of calendar time. The team developing a Specification creates some kind of artifact and submits it to the Specification Committee for review. The Specifiation Committee has a short amount of time to review the submitted artifact and conduct a ballot among its members to approve or not-approve that artifact under review. This guide contains a sufficient explanation of Review, but if you want the full definition, see the Eclipse Foundation Specification Process and the Eclipse Foundation Development Process.

Jakarta EE仕様策定委員会の運営

webdev@eclipse-foundation.org (Eclipse Foundation) — Wed, 13 Jan 2021 00:00:00 +0000

このドキュメントでは、Jakarta EE仕様策定委員会の実務について説明します。

このドキュメントへの変更は、Jakarta EE仕様策定委員会（jakarta.ee-spec@eclipse.org）のメーリングリストを通じて行われるJakarta EE仕様策定委員会の単純な多数決により承認される必要があります。

これは公開文書です。

仕様策定委員会

Jakarta EE仕様策定委員会は、Jakarta EEワーキンググループの管轄下で、すべての仕様プロジェクト（この用語はEFSPによって定義）の Eclipse Foundation Specification Process（EFSP）を実装する責任を負います。これには、 Jakarta EE Specification Process（JESP）と呼ばれる、Jakarta用 EFSPの適応が含まれます。

仕様策定委員会は、ワーキンググループの仕様プロジェクトによって作成された最終仕様の妥当性の確認に対して最終的な
責任を負います。「妥当である」という定義は、仕様策定委員会の参加者によって異なりますが、一般的には、仕様が実装可能であり、本質的クレームに関するEclipseの知的財産ポリシーの側面が遵守されていることを意味すると理解されています。実際には、仕様策定委員会の参加者は、EFSPに従って、主要なライフサイクルイベントを承認するために必要な投票を通じて権限を行使します。

仕様策定委員会は、仕様プロジェクトの運用ガイダンスドキュメントを作成、発行、維持する責任を負います。これには、最終仕様を作成するための最小要件とプロセスが含まれます。また、互換性をテストする目的で仕様TCKを実行する操作ガイダンスも含まれます。

仕様策定委員会の委員長（またはその代理）は、投票の開始、結果の集計、コミュニティへの伝達、また（適切な場合、例えば、Releaseレビューの投票の場合）結果を EMOに報告します。

仕様策定委員会は、また、その管轄下にある仕様プロジェクトに対して、 EFSP/JESPを実施する方法を定義し、改善する責任を負います。

プロジェクト管理委員会（PMC）

PMCの主な役割は、プロジェクトチームが Eclipse開発プロセスを実装していることを確認することです。特にPMCは、プロジェクト活動を監視して、プロジェクトチームがオープンで透明な方法で確実に作業を行えるようにします。PMCがコミッターの選挙をレビューおよび承認（または否認）します。まず、コミッター候補者が十分な利点を示していることを検証します。

PMCは、さらに、プロジェクトチームが Eclipse IPポリシーを遵守し、IPデューデリジェンスのプロセスを実施する責任を負います。実際には、PMCは知的財産貢献（CQs）を承認し、知的財産に関する（限定的な）ガイダンスをプロジェクトチームに提供します（必要に応じてEclipse IPチームに委ねます）。

PMCは、トップレベルプロジェクトの構造と、それに含まれるオープンソース（ソフトウェアと仕様）プロジェクトの組織化に責任を負います。

PMCは、プロジェクトリーダーシップチェーンの一環です。そのため、PMCは苦情処理プロセスでの役割を担います。プロジェクトの機能不全を特定して文書化します（破壊的なコミッターを削除/更迭/追加する責任があります）。

PMCは、オープンソースプロジェクトの運営に関するその他の監督も行います。ReleaseレビューおよびProgressレビューに関する資料をレビューし、承認します。また、トップレベルプロジェクト内のプロジェクト間のコミュニケーションを促進します。

プロジェクトリードの指名

仕様プロジェクトでは、プロジェクトリードとして 1人以上のコミッターを指名する必要があります。リードは、プロジェクトが適切なマイルストーンに到達したときに、レビューを開始する責任があります。

EclipseプロジェクトによるJakarta®ブランドの適切な使用

webdev@eclipse-foundation.org (Eclipse Foundation) — Tue, 03 Mar 2020 13:10:00 -0400

ブランド管理の重要な側面は、ブランドが表すもの、そのブランドのラベルが何かに付与される場合に満たされるべき期待に関する混乱を避けることです。「Jakarta」というラベルを付与する場合、つまり「Jakarta」を目的語/名詞の修飾語/形容詞として使用する場合 (例えば「Jakarta® Faces仕様」)、その意味を明確に示すことが重要です。また、プロジェクト空間で使用される方法の管理もこれに含まれます。名称を注意深く使用することにより、コミュニティはJakartaブランドが直接表すものと、そうでないものをより良く理解することができます。

Jakarta EE仕様策定委員会の下で開発された仕様は、仕様名に形容詞形式でJakartaブランドを使用する必要があります(すなわち、「Jakarta® [EE] X」)。たとえば、「Jakarta® EE Full Platform」や「Jakarta® Enterprise Beans」などです。Jakartaブランドのその他すべての使用では、目的語として「Jakarta」を使用する必要があります (例:「X for Jakarta® [EE]」)。どちらの形式でも「EE」を含めることはオプションと見なされます (プロジェクトチームの裁量に委ねられます)。

また、Jakarta EEワーキンググループの管理下で仕様を作成するEclipseオープンソース仕様プロジェクトのみが、仕様プロジェクト名に形容詞形式でブランドを使用できます。たとえば、「Jakarta® Servlet」仕様プロジェクトでは「Jakarta® Servlet」仕様となり、「Jakarta® Stable APIs」仕様プロジェクトでは「Jakarta® XML Registries」および「Jakarta® Deployment」仕様となります。他のすべてのEclipseオープンソースプロジェクト (およびEclipse Foundationの範囲外のすべての用途) では、名前に用語を含める場合、「for Jakarta®」形式を使用する必要があります (例:「Jakarta® EE向けEclipse Webツール」)。

つまり、このようになります (このリストは完全ではない可能性があります)。

Jakarta® EE Examplesプロジェクトの名前は「Examples for Jakarta® EE」に変更されます。

以下に注意してください。

商標登録されている用語は「Jakarta EE」ではなく、「Jakarta」です。商標に関する注記は、商標を付した用語に適用する必要があります (すなわち、「Jakarta EE®」ではなく「Jakarta® EE」)。
「Jakarta」は現在、EUおよび米国で登録されているため、すべての文書およびWebページで最初に使用される用語に「®」を含める必要があります。

仕様を採用する

webdev@eclipse-foundation.org (Eclipse Foundation) — Sat, 01 Feb 2020 16:09:45 -0400

このプログラムは、Jakarta EE仕様を採用することで、JUGリーダーや会員の参加を奨励することを意図しています。目的は、Jakarta EE仕様の進化への開発者の参加を増やすことです。

Adopters

JUGリーダーの支援方法:

例えば、既存のJUGのミートアップの一部を採用された仕様に関する議論にあてたり、グループ内でプログラムを実行しているJUGの代表者全員と毎月電話会議を行うなど、採用されたJakarta EE仕様の話題が一貫して議論されるようにします。

JUGメンバーの参加方法:

仕様開発に参加する（API/仕様書/TCK/実装）
仕様に関するブログを作成し、JakartaBlogsに追加する
ソーシャルメディアで仕様を宣伝する（例: twitter）
完全なエンドツーエンドテストWebアプリケーション（Pet Store for Jakarta EEなど）を書く
仕様を読み、不明な点があればコメントを入れる
既に存在するテストの上にさらにテストを書き込む
- すべてのリポジトリは、Jakarta EE GitHub Organizationの下にあります: https://github.com/jakartaee
- 例1 – Jakarta Servlet: https://github.com/jakartaee/servlet
- 例2 - Jakarta Messaging: https://github.com/jakartaee/messaging

JUGに提供できること:

採用された仕様ページにJUGを掲載し、JUGの認知度を高める
JakartaOne Livestream（ローカルエディション）を開催する際に、JUGを優先されるようにする（フレームワークとツールを提供する）
JUGがJakarta EEリリースパーティーを開催できるようにする（例: 年に1度のJakarta EEリリースパーティーにJakarta EEプレゼンテーション資料と景品を提供する）
EclipseConの「ハッカースペース」でAdopt-a-Spec活動を促進する
EclipseConやその他の主要イベントで「専門家に会う」非公式会合/Tech Talksを開催する
Jakarta EE Livestreamイベントに関するライブコードアロングセッションに参加する機会を得る
Jakarta EE関連の話題について話し合うために、Jakarta EE委員会または専門家とのミーティングに参加する機会を得る

登録方法:

ご登録の際には、下記の情報をご提供ください: 参加を希望する仕様名、JUGのWebサイトへのURL、およびJUGロゴ。Jakarta EEプルリクエストを作成する手順は以下の通りです。

Oracle/JCPの頭字語のガイドライン

webdev@eclipse-foundation.org (Eclipse Foundation) — Wed, 26 Jun 2019 16:10:38 -0400

既存のOracle/JCPの頭字語の使用に関するガイドライン。Eclipseのロゴ・商標ポリシーに関するEclipse Foundationガイドラインの補足。

バージョン 1.0 - 2019年6月26日

これらのガイドラインの目的は、混乱を避けること、また開発者コミュニティがJakarta EEプロジェクト、仕様、テストスイート、またはその他の関連アイテムがOracle/JCPから生成されたものか、Eclipse/Jakarta EEプロセスから生成されたものかを容易に特定できるようにすることです。

Oracle/JCPの頭字語のリストは、このドキュメントの下部に表示されます。

Jakarta EEプロジェクト、仕様、テストスイート、およびその他の関連資料の名称ついては、完全なプロジェクト名/タイトルおよびスコープステートメントに、特定の頭字語を組み込まないでください。

OK:「Jakarta Message Service仕様」
良くない例：「JMS仕様」
良くない例：「Jakarta Message Service (JMS)仕様」

Jakarta EEプロジェクトの現在のショートネーム（またはid）は、Oracle/JCPの頭字語（jaxrs-api、jaf、jpa-apiなど）から派生している場合があります。これらのプロジェクト用に作成されたリポジトリについては、次のGitHub組織名で、これらのプロジェクトに対する現在のショートネームを引き続き使用できます。

eclipse (例： github.com/eclipse/[現在のショートネーム])
eclipse-ee4j
jakartaee
eclipse-jakartaee

Eclipse Foundationで作成されたプロジェクトの場合は、次の形式のURLで、これらのプロジェクトの現在のIDとショートネームを使用しても問題ありません。

eclipse.org/projects/[現在のid]
projects.eclipse.org/projects/[現在のショートネーム]

最大限の柔軟性と明確性を実現するために、プロジェクトでは、妥当な場合は、新しい仕様名に近いショートネームに変更することをお勧めします。また、可能であれば、Oracle/JCPの頭字語を避けることをお勧めします。

仕様文書（または関連資料）にOracle/JCPの頭字語への参照が含まれている場合は、次のような文を含めてください。 _「このドキュメントのJMSへの参照は、特に断りのない限り、Jakarta Message Serviceを指します。」_文は読みやすいサイズである必要があり、判読できないほど小さな脚注ではなく、仕様文書（または関連資料）の最初の部分に表示される必要があります。読み手は文章を読むためにスクロールしたり、ページをめくったり、リンクをクリックする必要はありません。

URL、リポジトリ名、パッケージ名、クラス名、またはメソッド 名には、EclipseまたはJakartaを起点として識別する文字列の右側に頭字語を含めることができます。

OK: github.com/eclipse-ee4j/jms
OK: eclipse.org/projects/ee4j.jms
OK: jakarta.jms.JMSContext

プロジェクトの電子メールアドレスには、@（アットマーク）の左側に頭字語を含めることができます。

OK: jms-dev@eclipse.org

Mike Milinkovich氏がJava商標に対するJakarta EEの権利に関する更新のブログ記事で述べたように、

「javaxパッケージ名前空間は、Jakarta EE仕様内で使用できますが、『現状のまま』でのみ使用できます。Jakarta EEコンポーネントの仕様内でjavaxパッケージ名前空間を変更することはできません。javaxパッケージ名前空間を引き続き使用するJakarta EE仕様は、対応するJava EE仕様とTCKの互換性を維持する必要があります」

Jakarta EE 8は、このガイダンスに従って、『現状のまま』変更せずに、既存のjavax名前空間を使用して、既存のJava EE 8パッケージ名を使用します。Jakarta EE 9以降で、既存のJakarta EE 8およびJava EE 8のパッケージ/APIに変更がある場合は、新しい（javaxではない）パッケージ名を使用する必要があります。パッケージの名前付けに関する上記のガイダンスを参照してください。

ニュースレター

webdev@eclipse-foundation.org (Eclipse Foundation) — Mon, 04 Jun 2018 10:00:58 -0400

Jakarta EE Newsletters Archives

2020

2019

2018

FAQ

webdev@eclipse-foundation.org (Eclipse Foundation) — Sat, 07 Apr 2018 16:09:45 -0400

よくある質問

Jakarta EEとは？

Jakarta EEは、クラウドネイティブで、軽量で、かつ、従来型のエンタープライズJavaアプリケーションの未来です

Java EE技術Oracleによって提供されていたJava EE技術が、新しいJakarta EEプラットフォームの作成に使用されます
Eclipse Foundationは、クラウドネイティブJavaのオープンイノベーションの本拠地です
Jakarta EEワーキンググループは、Java EE技術とガバナンスプロセスをモダナイズし、よりオープンでコミュニティに基づくものにすることに重点を置いています

「Jakarta EE」という名前は何を意味しますか？名前の由来は何ですか？

Javaの初期の頃、Apache Jakartaプロジェクトは、Javaエコシステムにおける多くのエキサイティングなイノベーションの本拠地で>した。特にJavaプラットフォームの内外に強いオープンソースコミュニティを築く上で、大きな役割を果たしました。Wikipediaによると、この名前は元々、Sun Microsystemsでプロジェクトの作成に至った会議に使用された会議室であったために選択されました。

2018年2月、コミュニティはJava EEの新しい名前に投票することを歓迎されました。私たちのコミュニティ投票では、ほぼ7,000人のコミュニティが投票し、64%以上がJakarta EEに賛成しました。名前選択の歴史的背景については、Java EE to Jakarta EE読んでください。Jakartaが2011年にApacheでのプロジェクト終了後、Apache Software Foundationは、親切にもEclipse Foundationにその名前を使い始めることを許可しました。

Jakarta EEプラットフォームには何が含まれていますか？

当初、Jakarta EEはJava EE 8プラットフォームと完全に同等でした。Java EE 8を構成するすべての仕様、参照実装(RI)、およびTechnology Compatibility Kit (TCK)がEclipse Foundationに移管されました。以降のJakarta EEリリースは、この基盤の上に構築されます。

Jakarta EE商標ガイドライン

webdev@eclipse-foundation.org (Eclipse Foundation) — Thu, 05 Apr 2018 16:10:38 -0400

Jakarta EEマークに関するEclipseのロゴ・商標ポリシーのEclipse Foundationガイドラインの補足

バージョン1.2 - 2020年3月12日

このドキュメントは、Eclipse Foundation Eclipseのロゴ・商標ポリシーのガイドライン（本補足文書は、Eclipse FoundationのEclipseのロゴ・商標ポリシーに関するガイドラインと合わせて、総称して「ポリシー」と呼びます）を補足し、Jakarta EEマーク（以下に定義）の許可される使用について説明するものです。Jakarta EEマークには、次の名前および/またはロゴが含まれますが、これらに限定されません。Jakarta EE、Jakarta EEワーキンググループ、Jakarta EEメンバー、Jakarta EE互換(総称して「Jakarta EEマーク」)。Jakarta EEマークの使用に関する完全なガイドラインは、Jakarta EEブランド使用ハンドブックに記載されています。Jakarta EEマークの使用は、常に本ポリシーに準拠する必要があります。

Jakarta EEマークの使用は、以下のように制限されています（適格要件）。

「Jakarta EE互換」マークの使用は、互換ソフトウェア製品と組み合わせて使用する場合に限られます。「互換ソフトウェア製品」とは、その時点のTCKプロセスにおいて、Technology Compatibility Kit (「TCK」)の使用によってJakarta EEプロファイルの互換実装として認定された製品を指します。これらの用語は、その時点のJakarta EE仕様プロセスに定義されています。
「Jakarta EE互換」マークの使用は、以下によって配布される互換ソフトウェア製品（以下に定義される）と組み合わせて使用する場合に限定されます。 1.Jakarta EE WG のParticipant、Enterprise、またはStrategicメンバーで、且つJakarta EE Compatibility Trademark License Agreementに基づくライセンシーである場合、または 2.次の場合、Jakarta EEワーキンググループのGuestメンバーである。
Jakarta EE互換マークの使用がJakarta EE WG運営委員会により全会一致で承認されている、および
かかるGuest メンバーは、Eclipse Foundation商標ライセンスに基づくライセンシーでもある。
Jakarta EEワーキンググループの良好な立場にあるStrategicメンバーは、次の場合、Jakarta EEの互換ソフトウェア製品の公式リストに含まれるオープンソースの互換アプリケーションサーバー、および会社名、会社のWebサイトへのリンク、オープンソースプロジェクトへのダウンロードリンクを含める権利があり、そこでユーザーは互換アプリケーションサーバーを入手できます。
Jakarta EE運営委員会の承認、
メンバーは、Jakarta EE TCKプロセスに従って、該当するTCKを実行します。
メンバーおよびオープンソースプロジェクトは、Eclipse Foundation TCKライセンスのすべての要件に準拠しています。
製品ロゴは、オープンソースプロジェクトから入手可能であれば、互換ソフトウェア製品のJakarta EE公式リストに含まれます。これにより、Strategicメンバーは、オープンソース互換アプリケーションサーバーと組み合わせてJakarta EE互換ロゴを使用する権限を持ちます。また、Webサイトやその他のカタログに、互換ソフトウェア製品のJakarta EE公式リストへのリンクが含まれる場合もあります。

上記の適格要件を満たし、互換ソフトウェア製品のJakarta EE公式リストに含まれることを希望する製品については、次の情報を提供する必要があります。

製品またはオープンソースプロジェクトの名前とバージョン、
製品ロゴ（オプション）、
互換ソフトウェア製品をサポートするParticipant、Enterprise、またはStrategicメンバーの名前、
TCKプロセスで定義された、互換性を示す公開されている公開TCKテスト結果へのURL、
互換ソフトウェア製品またはオープンソースプロジェクトをダウンロードできるURL

さらに、

webdev@eclipse-foundation.org (Eclipse Foundation) — Mon, 01 Jan 0001 00:00:00 +0000

Creation Review PR template

When creating a specification project plan review, create PRs with the content defined as follows.

Link to Specification Project:

Include the following in the PR:

An index page wombat/_index.md following template
Title should be on the form “Jakarta Wombat”

webdev@eclipse-foundation.org (Eclipse Foundation) — Mon, 01 Jan 0001 00:00:00 +0000

Plan Review PR template

When creating a specification project plan review, create PRs with the content defined as follows.

Include the following in the PR:

A directory in the form wombat/x.y where x.y is the release major.minor version.
An index page wombat/x.y/_index.md following template
Title should be on the form “Jakarta Wombat X.Y (under development)”
Includes a plan for the release. Usually, a couple of statements is enough. Otherwise, a link to a document describing the release.
Includes a detailed description of any backward incompatibility (Mark with N/A and check if none)
Declares optional features if there are any (Mark with N/A and check if none)
Includes minimum Java SE version
Describe any updates or required changes including splitting out the TCK (Mark with N/A and check if not planned)
Link to updated release record

webdev@eclipse-foundation.org (Eclipse Foundation) — Mon, 01 Jan 0001 00:00:00 +0000

Progress Review PR template

When creating a specification project plan review, create PRs with the content defined as follows.

Include the following in the PR:

A directory in the form wombat/x.y where x.y is the release major.minor version.
An index page wombat/x.y/_index.md following template
Title should be on the form “Jakarta Wombat X.Y (under development)”
Specification PDF in the form of jakarta-wombat-spec-x.y-Mn.pdf
Specification HTML in the form of jakarta-wombat-spec-x.y-Mn.html
For a Progress Review, that sufficient progress has been made on a Compatible Implementation and TCK, to ensure that the spec is implementable and testable.
Link to updated release record

webdev@eclipse-foundation.org (Eclipse Foundation) — Mon, 01 Jan 0001 00:00:00 +0000

Specification PR template

When creating a specification project release review, create PRs with the content defined as follows.

Include the following in the PR:

A directory in the form wombat/x.y where x.y is the release major.minor version, and the directory contains the following.
Specification PDF in the form of jakarta-wombat-spec-x.y.pdf
Specification HTML in the form of jakarta-wombat-spec-x.y.html
A specification page named _index.md following the template at: https://github.com/jakartaee/specification-committee/blob/master/spec_page_template.md
For a Progress Review, that sufficient progress has been made on a Compatible Implementation and TCK, to ensure that the spec is implementable and testable.
For a Release Review, a summary that a Compatible Implementation is complete, passes the TCK, and that the TCK includes sufficient coverage of the specification. The TCK users guide MUST include the instructions to run the compatible implementations used to validate the release. Instructions MAY be by reference.
- Updated release record
- Generated IP Log
- Email to PMC
- Start release review by emailing EMO
The URL of the OSSRH staging repository for the api, javadoc:
The URL of the staging directory on downloads.eclipse.org for the proposed EFTL TCK binary:
The URL of the compatibility certification request issue:
Specification JavaDoc in the wombat/x.y/apidocs directory. If desired, an optional second PR can be created to contain just the JavaDoc in the apidocs directory.

Note: If any item does not apply, check it and mark N/A below it.

webdev@eclipse-foundation.org (Eclipse Foundation) — Mon, 01 Jan 0001 00:00:00 +0000

specifications

This site is powered by Netlify.

webdev@eclipse-foundation.org (Eclipse Foundation) — Mon, 01 Jan 0001 00:00:00 +0000

Specification Service Release PR template

When creating a service release, create PRs with the content defined as follows.

Include the following in the PR:

The URL of the Eclipse Project release record:
The URL of the OSSRH staging repository for the api, javadoc:
The URL of the staging directory on downloads.eclipse.org for the proposed EFTL TCK binary:
The URL of the compatibility certification request (CCR) issue:
Specification JavaDoc in the wombat/x.y/apidocs directory.
Changelog file at this location describing service release updates, wombat/x.y/changelog.
Update wombat/x.y/_index.md accordingly.
Start service release review by emailing Specification Committee and referencing this PR.

Note: Specifications themselves do not have service releases. Only the associated API (limited to JavaDoc updates), JavaDoc, and TCK artifacts can have service releases. Thus, the Specification version does not use the third digit – only the x.y version is used in the Specification directory structure.

Developer portal

webdev@eclipse-foundation.org (Eclipse Foundation) — Mon, 01 Jan 0001 00:00:00 +0000

Develop with Jakarta EE

Build secure, portable, scalable, cloud native apps using Jakarta EE APIs.

Get started

Generate a Jakarta EE project template and begin building right away.

Join Jakarta EE

webdev@eclipse-foundation.org (Eclipse Foundation) — Mon, 01 Jan 0001 00:00:00 +0000

Become a member

Shape the future of enterprise Java

Join industry leaders and innovators driving Jakarta EE forward. As a member, you'll help guide the technology's evolution, influence key decisions, and gain visibility as part of the open enterprise Java ecosystem.

Learn about membership

Contribute to projects

Turn your expertise into impact.

Join our global community of developers and make your mark on the Jakarta EE platform. From code to documentation, every contribution helps strengthen open, cloud native enterprise Java.

Home on Jakarta® EE: クラウドネイティブJavaの新ホーム

Change Log

Jakarta EE 12

Jakarta EE 12 Platform

Jakarta EE 12 Web Profile

Jakarta EE 12 Core Profile

Change Log

Change Log

Change Log

Change Log

Change Log

Change Log

Change Log

Jakarta EEを使用する理由

JAKARTA EE IS CONTINUATION

Jakarta EE仕様プロセス

javaxからjakarta名前空間に関するエコシステムの進捗状況

Change Log

2022年Jakarta EE開発者アンケートが開始されました！

クラウドネイティブJavaの未来を形作る

Jakarta EEに参加しよう！

会話に参加する

貢献の方法

コミッターになる

Jakarta EE TCK Process 1.3

役割と制限

名前空間

TCKリリースの資料

最終TCKの承認

Change Log

Change Log

Change Log

Change Log

Change Log

Change Log

Jakarta EE互換実装と互換製品

Jakarta EEコンポーネント仕様の互換実装としてリストされる方法

Jakarta EEプラットフォームまたはJakarta EE Webプロファイルの互換製品として掲載される方法

Jakarta EE仕様プロセスガイド

Content

はじめに

Jakarta EE仕様策定委員会の運営

仕様策定委員会

プロジェクト管理委員会（PMC）

プロジェクトリードの指名

EclipseプロジェクトによるJakarta®ブランドの適切な使用

仕様を採用する

Adopters

JUGリーダーの支援方法:

JUGメンバーの参加方法:

JUGに提供できること:

登録方法:

Oracle/JCPの頭字語のガイドライン

ニュースレター

Jakarta EE Newsletters Archives

2020

2019

2018

FAQ

よくある質問

Jakarta EEとは？

「Jakarta EE」という名前は何を意味しますか？名前の由来は何ですか？

Jakarta EEプラットフォームには何が含まれていますか？

Jakarta EE商標ガイドライン

Creation Review PR template

Plan Review PR template

Progress Review PR template

Specification PR template

specifications

Specification Service Release PR template

Developer portal

Develop with Jakarta EE

Get started

Join Jakarta EE

Become a member

Shape the future of enterprise Java

Contribute to projects

Turn your expertise into impact.