 
 
  |
|
Java 仕様開発プロセス使用時の公式手順 コメントの送付先:
pmo Copyright (c) 1996 - 2002 Sun Microsystems, Inc. 目次
概要
国際的な Java コミュニティは、Java Community Process (JCP) を利用して JavaTM テクノロジ仕様を開発し、発展させています。JCP は、仕様、リファレンス実装 (仕様が実装可能であることを証明するため)、およびテクノロジ互換性キット (実装が仕様に準拠していることを確認するためのテスト、ツール、および文書) を作成する包括的かつ合意主義のアプローチを採用して、「インターネット時間」で高品質な仕様を生み出しています。 これまでの経験から、テクノロジ仕様を作成する最良の方法は、問題のテクノロジに関する深い理解を持つ業界の専門家グループを召集し、グループとともに強力な技術リードが第 1 次ドラフト作成に取り組むことです。次に、レビュープロセスを繰り返して、文書のレビューおよびコメントを提供する聴衆を拡大してその合意を得ることにより、ドラフトの形式と内容を確立します。 このバージョンの JCP は、Sun および専門家グループとして一体化された Executive Committee の主導により、JSR 99 と JSR 171 を使用して JCP によって開発されました。 Java コミュニティの主要な出資者とその他のメンバの両方を代表する Executive Committee (EC) が、JCP の重要な局面で仕様文の承認、および仕様とそれに関係するテストスイート間の矛盾の解決を担当します。EC には 2 つの組織が存在します。 一方は、デスクトップおよびサーバ用途の Java テクノロジを監督 (J2SETM および J2EETM 仕様を担当) し、他方はコンシューマおよび組み込み用途の Java テクノロジを監督 (J2METM 仕様を担当) します。 このバージョンの JCP には、4 つの主要な段階があります。
Java Community Process (JCP): この文書で解説する、Java テクノロジ仕様の開発や改訂を行う公式プロセス。 Java Community Process メンバ (メンバ): JSPA に署名し、その条件に従う企業、組織、または個人。 Java Specification Participation Agreement (JSPA): Sun Microsystems と企業、組織または個人間で締結する、1 年ごとに更新可能な契約。この契約を締結することで、Java Community Process への参加が可能になります。 Individual Expert Participation Agreement (IEPA): 仕様リードの推薦により専門家グループへの参加を可能にする、Sun Microsystems と個人との間で締結される契約。IEPA に関して費用はかかりません。これは専門家グループが解散するまで継続して有効です。IEPA により、企業や組織を代表しない技術者が個人として専門家グループに参加可能になります。 Executive Committee (EC): Java テクノロジの発展を指揮するメンバ。EC は、Java コミュニティの主要な出資者とその他のメンバの両方を代表します。EC で活動するために、メンバは EC 同意書に署名する必要があります。EC のポリシーおよび作業手順については、付録 A を参照してください。 Program Management Office (PMO): JCP の運営を担当し、Executive Committee の議長を務める Sun Microsystems 内部のグループ。 Java 仕様 (仕様): Java テクノロジの特定分野を扱う仕様書。対象となるテクノロジには、言語、仮想マシン、Platform Edition、プロファイル、およびアプリケーションプログラミングインタフェースが含まれます。 Platform Edition 仕様 (Platform Edition): 基準の API セットを定義する仕様。アプリケーション、その他の API、およびプロファイルは、この API セットの提供する基盤の上に作成されます。現在、J2SE、J2EE、および J2ME の 3 つの Platform Edition 仕様があります。 プロファイル仕様 (プロファイル): いずれかの Platform Edition 仕様、およびその他の 0 個以上の JCP 仕様 (まだ Platform Edition 仕様の一部になっていない仕様) を参照する仕様。Platform Edition 仕様で規定された参照ルールに従い、参照先の Platform Edition の API を含める必要があります。参照されるその他の仕様は、そのままの状態で参照されるようにする必要があります。 リファレンス実装 (RI): 仕様のプロトタイプまたは「概念実証」実装。 テクノロジ互換性キット (TCK): 実装が仕様に準拠しているかどうかを確認するために、仕様の実装者が使用するテスト、ツール、および文書。 JCP Web サイト: インターネットに接続可能であればだれもが使用できる、JCP 活動の定期的な情報取得、ドラフトおよび最終仕様のダウンロード、および JCP での仕様の進捗状況の追跡を行う Web サイト。 JCP 仕様ページ (仕様ページ): 開発または改訂が承認済みの各仕様は、JCP Web サイト上の専用の Web ページに公開されます。この Web ページには、 ドラフト仕様に関する EC の決定、行動、および投票の記録を含む、JCP での仕様の履歴が掲載されます。 JAVA COMMUNITY PROCESSSM プログラム 1. 新規仕様または改訂仕様の提案
1.1 Java Specification Request の提案
1 人または複数のメンバが、JSR を PMO に送付することにより、新規仕様の開発要求または既存仕様に対する重要な改訂を提案できます。 JSR は、JCP Web サイトで入手可能なテンプレートを使用する必要があります。JSR は、要求を行うメンバ (申請者)、仕様リード、および専門家グループの初期メンバを識別するのに役立ちます。JSR には、提案された仕様、それを開発または改訂する理由、主要な対象となる Java Platform Edition、予測される開発スケジュール、既存の文書、テクノロジの詳細、または基盤に使用する実装に関する解説も含まれます。申請者は、検討中の JSR を、JSR の承認投票終了前 (セクション 1.3 を参照) であれば、PMO に対して要求することによりいつでも説明なしで取り下げることができます。 1.1.1 既存仕様の改訂既存仕様、関連する RI および TCK の保守は、この文書のセクション 4 で解説するプロセスを使用して、指定された保守リードにより行われます。保守リード (およびその所属企業または組織) には、発展を願う Java コミュニティメンバの意思を尊重し、仕様、RI、および TCK の保守を長期間担当することが期待されています。これは、保守リードが、以降の重要な仕様改訂すべてで自動的に仕様リードになることを意味しますが、重要な改訂時に独占的な決定権を持つことを意味するものではありません。重要な改訂の決定は、Java コミュニティメンバ (つまりメンバ) が提案可能な改訂 JSR に対応して、EC が行います。提案者は、当然、以前の専門家グループのメンバに改訂作業への参加を依頼するよう努力しなくてはなりません。 1.1.2 インストールベースの保護および断片化の防止Java プログラミング言語、Java 仮想マシン (JVM)、Java Native Interface (JNI)、"java.*" スペース内のパッケージ、または J2SE の一部として配布されるほかのパッケージに対する変更が、複数の Platform Edition 間で一貫性を欠く方法で行われると、インストールベースを著しく混乱させる危険性があります。インストールベースを保護するため、これらの変更の受け入れおよび実行は、J2SE 用の UJSR 内部でのみ行うことができるようになっています。 断片化を防止するため、新規 Platform Edition 仕様が、既存の Platform Edition またはプロファイルを実際に複製することはありません。 1.1.3 現行の Platform Edition をターゲットにするプロファイルおよび API 仕様新規仕様または改定された仕様は、すべてターゲットの Platform Edition 仕様の最新バージョンとの互換性を保持している必要があります。これを満たすため、新規プロファイル仕様定義用、または既存プロファイル仕様改訂用の UJSR はすべて、基盤にする最新バージョンの Platform Edition 仕様を参照する必要があります。 1.1.4 J2ME プロファイルおよび J2ME 構築ブロック定義 - J2ME 構築ブロック (構築ブロック): J2SE または J2EE Platform Edition 仕様で定義された 1 つ以上の API のサブセット。J2ME Platform Edition 仕様は、構築ブロックを集めたものです。J2ME プロファイル仕様は、新規 API セットを既存の構築ブロックと結合することにより、目的の機能を作成できます。 J2ME プロファイルは通常、既存の Java 仮想マシンおよび言語仕様に基づいています。この種のプロファイルにも J2SE や J2EE の機能のサブセットを含める必要がある場合、J2ME 構築ブロックへの参照が行われます。 構築ブロックは、J2ME Platform 仕様の UJSR 内で作成および改訂されます。J2ME プロファイルが異なると、必要とする J2SE/J2EE サブセットも異なる場合があります。たとえば、デバイスのカテゴリが異なると、必要とする "java.net" パッケージのサブセットも異なる場合があります。これに対応するため、J2SE/J2EE 機能を J2ME 構築ブロックにパッケージ化する回数や方法に基本的な制限は課されません。 構築ブロックの提案は、J2ME 仕様の UJSR 内で行うことができます。ただし、コンシューマおよびデバイス向けの市場は、デスクトップおよびサーバ向けの市場に比べ、急速に変化する可能性が高いことが認められています。J2ME プロファイルが市場のニーズの変化についていくために、新規構築ブロックの定義 (および既存の構築ブロックの改訂) を迅速に行うことが必要です。速度を向上させるために、J2ME 構築ブロックも J2ME 仕様の JCP 保守サイクル内 (セクション 4.2 を参照) で定義および改訂可能です。 J2ME 構築ブロックを迅速に作成または更新する必要のある専門家グループは、J2ME Platform Edition 仕様の保守リードに交渉し、要求を伝える必要があります。J2ME の保守リードは、ブロックを導出する Platform Edition の J2ME 専門家グループおよび仕様リードと協議した後で、新規の構築ブロックを J2ME 仕様の保守更新の一部として提案できます。EC は、J2ME 仕様の大幅な改訂時に定義される保守サイクルの一部として提案される任意の構築ブロックを要求できます (セクション 4.2.2 を参照)。 保守リードが構築ブロック要求を却下する場合、要求を提出した専門家グループには、J2ME 用の UJSR を発議するか (時間がかかる場合もある)、既存の Platform Edition 仕様で予約されていないネームスペースに必要な API を作成するという選択肢が残されています。 例外的に、J2ME 仕様が J2ME 構築ブロックを、Java 仮想マシンまたは言語仕様のサブセットだけを実装可能なデバイスの特殊クラスで使用するよう定義する場合があります。この種の構築ブロックの定義および承認は、J2ME 用の UJSR でのみ可能です。デバイスの特殊クラス用の構築ブロックの提案は、可能な限り広範なレビューを行う必要があるため、これらを保守サイクルを使用して定義することはできません。 1.1.5 継続的な可用性 JSR が定義するテクノロジは、プロファイルまたは Platform Edition の一部として、またはスタンドアロン、あるいはその両方として配布されます。 このテクノロジの将来のバージョンでは、以前のバージョンとは異なり、プロファイルまたは Platform Edition への統合が行われる可能性があります。 JSR の申請者が必要となり、申請者は JSR 申請フォームを使用して、JSR の RI および TCK をプロファイルあるいは Platform Edition の一部とするのか、スタンドアロンとするのか、あるいはその両方なのかを明示します。 JSR の RI および TCK を別々に配布するのではなく、プロファイルあるいは Platform Edition に統合して配布し、また以前のバージョンの RI および TCK が別々に利用可能な場合、申請者はその決定理由を説明する必要があります。 この場合は、JSR レビュー (セクション 1.2 を参照) は 14 日ではなく 4 週間になります。 API の新しいバージョン用の JSR が、プロファイルまたは Platform Edition の一部となるように提案し、さらにこの API 用の以前の JSR がこの計画を提示していないのにスタンドアロンへの可用性を中止する意向である場合には、1 つ前のバージョンでスタンドアロンでの可用性を中止することについての提案を行う必要があります。 1.1.6 プラットフォームへの取り込み JSR を Platform Edition またはプロファイルの定義に取り込みたい場合は、その意図を JSR の申請に記述する必要があります。 特定の JSR がプロファイルまたは Platform Edition に取り込まれるかどうかの最終決定は、Platform Edition JSR またはプロファイル JSR の仕様リードおよび専門家グループによってなされ、該当する JSR に対する投票によって確認されます。 Platform Edition JSR またはプロファイル JSR の取り込みについての要求が否決されると、その API 用の JSR では、スタンドアロン RI および TCK を配布する必要があります。 1.2 JSR レビュー
JSR を受け取ると、PMO は、JSR への追跡番号の付与、適切な EC への JSR の割り当て、JSR ページの作成、提案された JSR の公表、および JSR レビューの開始を行います。JSR に対するコメントは、JSR ページに掲載された電子メールアドレスに送信する必要があります。受け取ったすべてのコメントは、JSR ページから表示可能になり、 EC に転送されてそこで熟考されます。(JSR が承認された場合に) 専門家グループへの参加を考えているメンバは、PMO に推薦フォームを送信して、自分の存在を示す必要があります。 セクション 1.1.5 に記されているとおり、レビュー期間は 2 週間か 4 週間のいずれかです。 1.3 JSR 承認投票
JSR レビュー期間中、EC メンバは JSR (推薦された仕様リードおよび初期の専門家グループを含む) および受け取ったすべてのコメントや推薦をレビューしてから、JSR を承認するかどうかを決定する投票を行います。
JSR 承認投票が却下されると、PMO は EC のコメントをすべて JSR 申請者に送信します。JSR 申請者には、14 日以内に JSR を改訂して PMO に再提出する機会が与えられます。この期間内に改訂された JSR が受領されない場合、元の EC による決定が確立され、JSR は閉じられます。改訂された JSR を受領すると、PMO はそれを JSR ページに送信して、改訂された JSR を公表し、すべての EC メンバに送信して JSR 再審議投票にかけます。投票の結果、承認されない場合、JSR は閉じられます。
2.1 専門家グループの編成JSR が承認されると、PMO は認定された仕様リードに対し、専門家グループを形成するよう通知します。仕様リードを担当しているメンバが JSR の承認前にコミュニティから脱退すると、PMO は初期専門家グループに対してこの文書で定義されている任務 (RI や TCK に関する責任の担当、JSR で予測されるスケジュールの実行、セクション 4 で説明する保守リードの立場への就任を含む) を引き受ける交代要員をグループ内から選任することを求めます。 専門家グループには定員がありません。仕様リードは、既存の専門家グループに最初に指導を求めるという条件に従う限り、いつでも専門家を追加できます。たとえば、意見の多様性を拡大するという目的で、新メンバを追加する場合があります。仕様リードは、ほかのメンバに直接交渉して共に働き、専門家であることを確認してから、新たな専門家として専門家グループに任命します。個人の専門家は、IEPA に署名することにより専門家グループのメンバになります。 2.1.1 自由な作業スタイル各専門家グループは、もっとも生産的で適切と考えられる作業スタイルを、それが JCP に準拠している限り、自由に定義して従うことができます。インターネットの使用は、推奨されています。専門家グループでは、電話による会議およびグループミーティングに加え、メーリングリストを利用した電子メールの交換が確立されています。これらを利用して、ドラフトの発展に伴って発生する問題の討議や解決が行われています。直接対面式のグループミーティングは有用ではありますが、スケジュールを調整する必要があるために作業効率を著しく低下させる傾向があります。 2.1.2 専門家グループからの脱退専門家は、専門家グループからいつでも脱退できます。この場合、仕様リードは専門家を務めたメンバに交渉し、そのメンバと共に後任者を探します。そこで後任者が見つからない場合、仕様リードは必要に応じて、別のメンバを後任者として任命できます。脱退する専門家が仕様リードの場合、専門家グループはメンバの 1 人を新たに選び、そのメンバがこの文書で定義されたすべての任務を進んで引き受ける意思がある場合、仕様リードとして選任します。 2.1.3 非協力的または非同調的な専門家グループのメンバまれな場合ですが、ある専門家が専門家グループの作業を前進させる方法で活動していない、と同じグループのほかのメンバが感じることがあります。積極的に取り組み解決できるように、こうした懸念をできるだけ速やかに仕様リードや EC に伝達する必要があります。専門家グループには、グループ内のこの種の問題に道理にかなった方法で取り組み、問題を解決することが期待されています。専門家グループのメンバの 2/3 以上が、仕様リードが非同調的であり、時宜にかなった方法で状況に取り組んでいないと感じる場合、EC は PMO に働きかけ、仕様リードを選任したメンバに対し後任者の選任を求めることができます。 2.2 仕様の第 1 次ドラフトの作成専門家グループは、JSR に示された要件、寄稿された文書やテクノロジの解説、JSR レビューで受け取ったコメント、および既存仕様の改訂の場合には保守リードの保持する変更記録 (セクション 4 を参照) を最初に考慮する必要があります。ほかのメンバ、業界グループ、ソフトウェア開発者、エンドユーザ、および学者とのディスカッションから情報を取得することもできます。目標は、要件を定義し、コミュニティレビューに適するドラフトを作成することです。 専門家グループが第 1 次ドラフトのレビュー準備が完了したと判断したら、仕様リードがドラフトをレビューに必要なほかのファイルといっしょに PMO に送付します。コミュニティレビューの期間が最短の 30 日を超えると専門家グループが判断した場合、仕様リードがその期間も提案します。 2.2.1 RI および TCK のライセンス条件に関する初期の警告およびフィードバック仕様リードの企業または組織が、JCP 内部で使用するために確立されたライセンスガイドラインに沿った条件で、リファレンス実装 (RI) とテクノロジ互換性キット (TCK) およびそのライセンスを担当します。仕様リードは、コミュニティレビューまでに RI および TCK をライセンス許可する条件を EC に提示します。EC メンバは、その条件に対するコミュニティ全体としての対応を示すフィードバックを提供します。 2.3 コミュニティレビュー
PMO が JCP Web サイトにドラフト仕様を送信し、すべてのメンバにコミュニティレビューの開始を発表した時点から、ドラフト仕様の改良が始まります。コミュニティレビューの目的は、ドラフトの主な問題点を明らかにして訂正し、ドラフト仕様をできるだけ早くパブリックレビューに適したものにすることです。 メンバからのコメントはすべて、ドラフトに記載されているフィードバック送付先の電子メールに送信されます。仕様リードの役割は、メンバからのすべてのコメントに対する考慮および対応が確実になされるようにすることです。作業を簡略化するために、類似したコメントは一体化され、1 つのコメントとして処理されます。 2.3.1 コミュニティレビュー時のドラフトの更新専門家グループがコミュニティレビュー中に大幅な改訂を行う場合、仕様リードはレビュー期間の最終日の 7 日前までに、改訂されたドラフトを変更の概要説明と共に PMO に送信する必要があります (EC がドラフト仕様の承認投票を完了するため、ドラフトはコミュニティレビューの最後の 7 日間でフリーズします)。PMO は、受け取った更新済みのドラフトおよび変更の概要をすべてメンバに通知し、ダウンロード可能にします。 ドラフトとほかの仕様との重複、またほかの仕様がすでに提供している機能やサービスの複製を作成してしまうことを避けるため、EC メンバは、コミュニティレビューの間、所属する組織の 1 人以上の技術メンバにドラフトのレビューを依頼することを強く推奨されています。EC メンバは、こうした問題を発見したら、ドラフトに記載されているメンバのフィードバック用電子メールアドレスを使用して、専門家グループにすべて報告します。報告は、メンバのほかのコメントと同じように見なされ、処理されます。 2.4 ドラフト仕様の承認投票
ドラフト仕様の承認投票は、コミュニティレビューの最後の 7 日間に行われます。投票が終了すると、EC メンバにより送られたすべてのコメントおよび投票結果が、PMO により専門家グループに配布されます。
投票によりドラフト仕様が否決された場合、専門家グループはその後の 30 日間で EC による懸念に対応してドラフトを更新し、改訂したバージョンを PMO に送付する機会が与えられます。改訂されたドラフトを 30 日以内に PMO が受け取らない場合、EC による当初の決定が確定し、JSR は閉じられます。改訂されたドラフトを受け取った場合、PMO はそれを EC に転送して、ドラフト仕様の再審議投票が行われます。投票が終了すると、EC メンバにより送られたすべてのコメントおよび投票結果が、PMO により専門家グループに配布されます。この投票で否決されると、JSR は閉じられ、専門家グループは解散します。JSR が既存の仕様に対する改訂の場合、仕様リードは現行仕様の保守リードの役割を再開します (セクション 4 を参照)。 ドラフト仕様の承認投票 (または再審議投票) が可決されると、専門家グループは、EC 投票のコメントに応じて必要と見なされる変更をドラフトに加えてから、パブリックレビューを行うためにドラフトを PMO に渡します。 3. 仕様の完成
3.1 パブリックレビュー
EC がコミュニティレビューで承認したドラフト仕様を、PMO が JCP Web サイトで公開してメンバおよび一般ユーザにそのことを公表すると、パブリックレビューが始まります。インターネットにアクセス可能であればだれでも、ドラフトをダウンロードしてコメントを送付できます。パブリックレビューは、JCP の重要な一部です。過去において、一般からのコメントにより根本的な構造上および技術上の問題が明らかになり、その結果、仕様に重要な改良が行われてきました。 仕様リードは、一般からのすべてのコメントが確実に確認および考慮されるよう見届けます。送付されたコメントの結果、仕様の改訂が行われ、しかもその改訂が大規模な変更となる場合 (専門家グループの意見で)、仕様リードは更新されたドラフトを (変更の概要説明とともに) PMO に送付します。PMO はそれらを JCP Web サイトに公表し、メンバと一般ユーザに通知します。 3.2 最終ドラフト案
パブリックレビューの終了後、専門家グループは、受け取ったコメントから必要と判断した改訂を行うことにより、仕様の最終ドラフト案を準備します。仕様リードは最終ドラフト案を PMO に送付します。PMO は最終ドラフト案をメンバおよび一般ユーザに公表し、JCP Web サイトに公開してだれもがダウンロードできるようにします。 3.2.1 RI および TCK の完了仕様リードは、リファレンス実装 (RI) およびテクノロジ互換性キット (TCK) の完成を確認します。RI および TCK により、仕様に定義不足、不完全、または不明瞭な領域があることがわかった場合、仕様リードは専門家グループと協力してこれらの不備を改良し、改訂された仕様 (および変更の概要説明) を PMO に送付します。受け取った改訂および変更概要はすべて、JCP Web サイトに公開され、メンバと一般ユーザの両方に公表されます。専門家グループは、この期間中にも送付されるコメントを引き続き検討します。 3.2.2 第 1 レベル TCK 改訂請求プロセスの確立
仕様リードは、明確に定義された第 1 レベル TCK 改訂請求プロセスを確立し、TCK に含まれるテストに改訂を請求する作業も見届けます。TCK 内の文書に、このプロセスの解説を含めておく必要があります (TCK 改訂請求プロセス全体については、セクション 4.3 を参照)。単独の API 仕様から Platform Edition 仕様までの状況に適用可能な、第 1 レベル TCK 改訂請求プロセスの例は、JCP Web サイトの TCK セクションを参照してください。 3.3 最終承認投票
TCK が適切なテスト範囲を提供し、RI が適切な仕様を実装し、RI が TCK に合格することを専門家グループが確認すると、仕様リードは仕様の最終ドラフト、および EC メンバによる評価用 RI および TCK の入手方法を PMO に送付します。PMO が資料を EC に配布して、最終承認投票が行われます。投票の終了時に、すべての EC コメントが PMO により専門家グループに送付されます。
最終承認投票により却下された場合、仕様リードはその後の 30 日間で EC による懸念に対応して RI や TCK を更新する機会が与えられます。同時に、専門家グループには同じ 30 日間で EC による懸念に対応して最終ドラフトを改訂し、PMO に送付する機会が与えられます。 30 日以内に応答がない場合、EC による当初の決定が確定し、PMO により JSR は閉じられ、専門家グループは解散します。JSR が既存の仕様に対する改訂の場合、仕様リードは現行仕様の保守リードの役割を再開します (セクション 4 を参照)。 応答があった場合、PMO はそれをすべての EC メンバに配布して、最終承認の再審議投票が行われます。投票の終了時に、EC メンバに送信した投票のコメントがすべて、PMO により専門家グループに配布されます。再審議投票で却下された場合、JSR は閉じられ、専門家グループは解散します。JSR が既存仕様の改訂である場合、仕様リードは現行仕様の保守リードの役割を再開します。 3.4 最終リリース最終承認投票 (または再審議投票) で EC により承認された仕様は、PMO により JCP Web サイトに公開され、メンバと一般ユーザの両方にその情報が公表されます。最終リリースにより、専門家グループはその作業を終え、解散します。 4. 保守
4.1 仕様を最新の状態に保つ
保守リードは、仕様の保守および、仕様に記載された電子メールアドレスにメンバと一般の両方から送付される、仕様の明確化、解釈、および拡張に関する要求に対応することによって誤りを訂正するかどうかの対処を担当します。保守リードはすべての要求を考慮し、仕様を更新すべきかどうか、またその更新方法を決定します。通常、保守リードが仕様を開発した専門家グループの仕様リードを務めます。保守リードには、これらのタスクすべてを自分自身で行うことが求められるわけではありません。保守リードは、仕様を開発した専門家グループのメンバを任命して保守作業を支援してもらうことができます。 4.1.1 保守リードには長期の任務が求められる保守リード (およびその所属する企業または組織) は、発展を願う Java コミュニティのメンバの意向に従って、仕様、RI、および TCK の所有権を長期間保持することが期待されています。これは、保守リードが、以降の重要な仕様改訂すべてで自動的に仕様リードになることを意味しますが、仕様の改訂をいつ行うかを決定する独占的な権利を保持するわけではありません (セクション 1.1.1 を参照)。 4.1.2 所有権の放棄
保守リードが、何らかの理由で任務を中止する場合 (保守活動を中止する場合や JSR により提案された重要な改訂作業で仕様リードとしての役割を拒否する場合を含む)、保守リードは当然、その任務を引き継ぐ別のメンバを見つける努力を払う必要があります。保守リードが後任を見つけることができない場合、PMO はその仕様が休止状態にあることを宣言します。新たな保守リードが特定され、仕様、RI、および TCK の所有権が新規保守リードの組織に委譲される (EC による委譲投票で承認される) まで、保守は行われません。 4.2 保守サイクル保守リードは、すべてのコメントをレビューし、共通したテーマを識別し、PMO と協議して頻繁に発生する問題のリストを文書の仕様ページから利用可能にします。保守リードは専門家グループの以前のメンバやほかの情報源に自由に問い合わせて、仕様の改訂方法に関するアドバイスを受けることができます。保守リードが提案した変更項目はすべて、小規模改訂プロセス (セクション 4.2.1 を参照) または JSR により、仕様に反映されます。 4.2.1 小規模改訂プロセス
保守リードは、すべての変更項目が変更記録の「PROPOSED」セクションに記載されるよう手配し、保守レビューの開始要求を PMO に送付します。PMO がそれを公表することにより、レビューが始まります。 保守リードは、レビューで受け取ったコメントに基づき、1 つ以上の変更案を修正できます。すべてのコメントは、仕様ページから入手できます。保守レビューの最後に、保守リードは仕様を更新し、すべての改訂を変更記録の「ACCEPTED」セクションに記載し、「PROPOSED」セクション内の対応するエントリを削除します。仕様にまだ反映していない すべての変更は、「PROPOSED」セクションに残されたままにするか、「DEFERRED」セクションに移動します。 4.2.2 EC による小規模改訂項目の保留
保守レビューの期間中、EC のメンバは、提案された特定の変更項目を次の JSR まで保留にすることを要求できます。この種の要求は、すべて保守レビューの終了 7 日前までに PMO に対して行う必要があります。要求が受理されると、PMO は要求をすべての EC メンバに配布し、レビューの最後の 7 日間で項目除外投票が行われます。保守レビューの終了時に、PMO は投票結果を変更記録に送信します。保守リードは、除外されたすべての変更案を「DEFERRED」セクションに配置します。これらの変更のいずれかを実行する場合、保守リードは JSR を開始する必要があります。 4.2.3 RI および TCK が仕様と同期した状態を保つ仕様を更新するたびに、保守リードは現行の RI と TCK をレビューし、RI および TCK が仕様と同期した状態を保つためにどのリビジョン (存在する場合) が必要かを見きわめる責務があります。RI および TCK が仕様と同期している場合、保守変更は最終版と見なされます。 4.3 TCK 改訂請求プロセスセクション 3.2.2 で説明したように、TCK 文書は、TCK の問題解決に使用する第 1 レベル TCK 改訂請求プロセスを特定および指定する必要があります。仕様の実装者は、第 1 レベル TCK 改訂請求プロセスを使用して TCK テストに取り組むことができます。第 1 レベルの決定に満足しない実装者は、EC にこれを請求できます。 4.3.1 EC への第 1 レベルの決定の改訂請求
実装者は、JCP Web サイトの TCK セクションで利用可能なオンラインフォームを使用して、記述された要求を PMO に提出することにより、第 1 レベルの決定を EC に改訂請求します。PMO は要求を、保守リードから受け取った第 1 レベルの決定理由に関する情報とともに EC に配布し、改訂請求投票を開始します。 4.3.2 TCK および仕様に合わせた RI の更新改訂請求投票により承認されると、保守リードは EC の決定に合わせて TCK や仕様を更新し、必要に応じて RI を更新します。 付録 A: Executive Committee のポリシーおよび作業手順
A.1 範囲Executive Committee (EC) は、JCP 内で、Java テクノロジの開発および発展を監督します。 A.2 メンバExecutive Committee は 16 の Java Community Process メンバおよび投票権を持たない議長で構成されます。EC の議長は、Process Management Office のメンバが務めます。投票権を持つ 16 のメンバは、Java Community Process メンバの中から選出されます。Sun Microsystems, Inc. は、EC 内に恒久的な投票権のある議席を保持します。Sun の代表者は、PMO のメンバにはなりません。 あるメンバが EC に 2 つ以上の議席を保持することは、どの時点でもありません。たとえば、メンバがほかの 1 つまたは複数のメンバの過半数の所有権を持つ場合、そのメンバ全体で EC 内に議席を 1 つだけ保持することができます。 A.3 任務および職責
A.4 EC の選出手順および任期
投票権を持つ EC のメンバの任期は 3 年です。信任議席が 10、選出議席が 5、および Sun Microsystems, Inc. の占める常任議席が 1 つ存在します。次に示すように、信任または選出される 5 つの議席が毎年交代し、3 年ごとに 15 議席すべてが入れ替わります。
3 年ごとにこのサイクルが繰り返されます。信任または選出議席が任期満了前に空席となった場合、セクション A.4.2 および A.4.3 に記載された手順で補充が行われます。 A.4.1 EC メンバの辞任投票権を持つ EC メンバは、任期中いつでも辞任できます。 投票権を持つある EC メンバが、投票権を持つ別の EC メンバの過半数の所有権を持つ場合、取得完了日までにいずれかのメンバが辞任する必要があります。 EC メンバが Java コミュニティのメンバでなくなった場合、EC の議席を失います。 A.4.2 信任議席の選出手順信任議席を占める 10 のメンバは、毎年 10 月の第 1 週に開始される信任選挙により選出されます。セクション A.4 の末尾の表に、3 年周期の各年に交代する信任議席数が示されています。 辞任により信任議席が任期満了前に空席となった場合、辞任から 2 か月以内に、残りの任期を務める議席の信任選挙が行われます (辞任から次回の定期信任選挙までの期間が 3 か月以内である場合を除く)。 信任選挙は、次の方法で行われます。
すべてのメンバが信任選挙の投票資格を保持します。ただし、あるメンバがほかの 1 人または複数のメンバの過半数の所有権を持つ場合、そのメンバ全体で 1 つの投票権を保持します。 A.4.3 選出議席の選出手順5 つの選出議席のメンバは、毎年 10 月の第 3 週に開始される選挙で選出されます。セクション A.4 の末尾の表に、3 年周期の各年に交代する選出議席数が示されています。 辞任により選出議席が任期満了前に空席となった場合、辞任から 2 か月以内に、残りの任期を務める議席の選出選挙が行われます (辞任から次回の定期選出選挙まで期間が 3 か月以内である場合を除く)。 選出選挙は、次の手順で行われます。
すべてのメンバが、選出選挙の投票資格を保持します。ただし、あるメンバがほかの 1 人または複数のメンバの過半数の所有権を持つ場合、そのメンバ全体で 1 つの投票権を保持します。 A.5 EC の投票規則このバージョンの JCP の投票規則を次に示します。
A.6 ミーティング
A.7 暫定 Executive Committee の構成
付録 B: JCP、JSPA、および IEPA の改訂
Java Community Process (この文書)、Java Specification Participation Agreement、および Individual Expert Participation Agreement の改訂は、Java Community Process により次の条件に従って実行されます。
|
