この標準情報(TR)は，2000年3月にNISTから公表された NIST Special Publication 500-243, Requirements for Real-time Extensions for the Java Platform を翻訳し，技術的内容を変更することなく作成した標準情報(TR)(タイプV)である。
この標準情報(TR)は，実時間Java規定の作成者・開発者，プロファイルの要件・規定作成者及び応用プログラム開発者のために，次の項目を規定する。
JavaTMプラットフォームの実時間拡張のための要件定義グループは，NIST(National Institute of Standards and Technology)によって発足させられた。 要件定義グループには，計算機業界及び大学を含めた，様々な企業及び組織からの代表者が集まっている。 業界からの参加者には，デスクトップシステム，サーバシステム及び企業システムの提供者，組込みシステム提供者，デバイス製造者，並びに実時間オペレーティングシステムベンダが含まれる。 要件定義グループは，6ヶ月の間に，一連の公開ワークショップを開催し会合をもった。 さらに，要件定義グループは，rt-java@Raleigh.ibm.comというメーリングリストで議論を継続した。 要件定義グループの目標は，JavaTMプログラム言語で書かれ，様々なプラットフォーム上で動作する実時間アプリケーションに必要な，実時間機能のための複数分野にまたがる要件を開発することであった。 この文書は，要件定義グループの努力の成果である。
この文書に含まれる要件は，グループの合意によって開発された。 そのために，要件が全体として，要件定義グループメンバ又はその所属組織のすべての意見を表現しているとは限らない。 要件定義グループ作業部会において，同意が圧倒的な場合にだけ，合意が宣言された。 明示的にそうではないと記述されていない限り，すべての要件に関して合意に到達している。 強い合意に達することができなかったものもある。 その場合には，その要件は，未決定 − 未合意，と記されている。
意見(原文書ではRationale)又は参考(原文書ではDiscussion)と記された内容は，合意に基づく内容ではなく，要件定義グループ全体の意見を表現したものと考えないほうがよい。 意見及び参考の段落は，要件定義グループのメンバによって書かれており，基本的には，その各々の著者の意見を表している。 これらの段落は，その要件を将来の規定に適用する人々への付加的情報を提供する点で役に立つ。
この0.の後に1.が続く。 1.で示す概念は，ワークショップ及びメーリングリストにおける実時間の理論及び応用についての議論に対して，基礎を提供した。 2.では，実時間Java要件を開発する動機となったJavaの優れた機能をまとめる。 3.では，要件定義グループがこの要件の基礎をまとめるに当たり使用した原理の一覧を示す。 この原理は，実時間Javaの将来の姿も提供する。 4.では，すべての実時間Java実装に存在し，基本的な規定で定義されることが望ましい必要な機能(コアの機能)に関する要件定義グループの洞察を示す。さらに，付加的な規定における付加機能の記述方法に関する洞察も示す。 5.では，要件定義グループが，コア実時間Java規定で示されなければならないと決定した要件の集合を定義する。 最後に，6.では，基本実時間Java規定のプロファイル又は将来版のいずれかで示されることが望ましい，一般的な目標及び付加的な派生要件を定義する。 なお，1.は，Mitre社のDoug Jensenによって提供された。 これら概念のより詳細は，http://www.real-time.orgを参照すること。
要件定義グループの最初の合意は，要件文書とは，Javaプラットフォームの"適時性"(timeliness)の特性を正確で実装非依存な方法によって規定できるものとする，ということであった。 すなわち，適時性(例えば予測可能性)特性とは，実装において通常に計測したタイミングでも，要求されているタイミングでもなく，プラットフォームの仕様に内在するものとする。 これは，従来とは異なる能力となる。 分かっている限りでは，これらの特性が書かれた仕様を基に作られた商用の実時間OSは存在しない。 特注品又は研究用の実時間OSでもほとんど存在しない。 この能力を達成するためには，正しく定義された概念及び用語を用いることが必要となる。 1.では，この標準情報(TR)で必要な実時間の概念を示す。
"実時間"(real-time)，"厳密な実時間"(hard real-time)，"厳密でない実時間"(soft real-time)，"確定性"(determinism)，"予測可能"(predictable)などの実時間計算の核となる用語は，実時間の開発者者(すなわち，ベンダ及びユーザ)のコミュニティで，定義されていないか又は誤って定義され，矛盾した方法で広く使用されている。 このコミュニティでは，"厳密な"実時間が何を意味するかについて合意はない。 しかし，"それを見ればそれが分かる"と信じているように思われる。 一方，"厳密でない"実時間は，非実時間システムに適用される語句である"なるようになる"を意味していると，通常は考えられている。 これは，実時間に関するよく知られたニュースグループ及び業界紙で，"実時間"とは何を意味するのかという話題に関する議論を読めばすぐ分かる。 "実時間"が何を意味するかについてのこの相違は，初期の要件定義グループの会議中でも見受けられ，多くのメンバは，実時間計算の核となる用語を未定義で矛盾のある様々な方法で，暗黙的及び明示的に使っていた。 会議でのこの初期の混乱によって，これら用語及び概念を明確化すべき必要性が確証された。
逆に，実時間計算研究コミュニティには，"厳密な実時間"の正確な定義があるが，結果的には，これは，開発者の典型的な利用法とは一切関わりが無い。 しかし，この研究コミュニティも，"厳密でない実時間"を"厳密な実時間ではない"という同義反復以上に定義することには失敗している。 研究コミュニティは，"予測可能性"(predictability)という用語も正確に定義しないで使用しており，通常は誤って"確定性"(deterministic)の同意語を意味していた。 逆に，例えば，"ジョブショップスケジューリング"(job shop scheduling)などの古典的スケジューリングのコミュニティには，"確定的スケジューリング"(deterministic scheduling)及び"確率的スケジューリング"(stochastic scheduling)の両方のための膨大な形式理論がある。 それらの概念及び用語のほとんどは，そのまま実時間計算に適用できる。 例えば，"期限"(deadline)などの基本的なものの幾つかは，実時間計算機スケジューリング理論においてよく知られている。 しかし，他の大部分のものは知られていない。 それでもなお，実時間計算には，ジョブショップスケジューリング理論には見い出せない概念及び用語が必要になる。
実時間計算は，適時性に関する二つの側面，すなわち，目標及びその目標への手段，を含む。 第1の側面は，目標である。 目標とは，アプリケーション，システム，OS，Javaプラットフォーム，スレッドなどの実体が，実時間で機能する程度，すなわち，適時性規定に従う許容できる適時性特性をもつ程度を示す。
許容される程度の適時性を達成するには，実時間計算の第2の側面，すなわち，目標に到達するための手段である実時間資源管理が関与することもあるし，関与しないこともある。 プログラマ又は計算システムのどちらが実時間資源管理を行うかにかかわらず，プロセサの性能などの資源の過負荷が，実時間資源管理の程度を低くしたり，必要性を無くしたりさえすることがある。
意見 時として, 人々は, 実時間計算を，システム(又はタスク)がその適時性の基準に合致するかどうかという目標に関してだけ考え，その手段(例えば, 資源の過負荷及び厳密な上限をもつサービス遅延によるもの，又は明示的な適時性基準(期限)によって駆動される資源管理によるもの)を無視することがある。それは, "実時間"として認識される資源管理技法をシステムが用いるかどうかに関係なく，多くの計算システムは，システムレベル又はアプリケーションレベルにおいて，適時性の基準をもつ活動を含んでいるからである。 システムレベルの例に，デバイスドライバがあり，アプリケーションレベルの例に，"かんばん方式"(just-in-time)の部品納入の期限がある。 一方別の時には, 人々は, 実時間計算を, 利用されている資源管理技法(通常の実時間オペレーティングシステムにおける優先度順ディスパッチ，及び短く厳密な上限が指定されたサービス遅延など)に関してだけ実時間計算を考えて, 明示的な完了時間制約(つまり，期限)及びスケジューリングの最適化の基準(例えば，すべての期限を満たすなど)をもつアプリケーションタスクについては全く考えないことがある。 これらの議論は，1.3.1に示す。
"スケジューリング"(scheduling)とは，スケジュールを作成することとする。 これは，資源が逐次的に再利用可能なとき，一つ以上の資源への競合するアクセスをどのように認めるかを規定する(半順序的な)順序リストとする。 資源は，プロセサ，通信経路，記憶機器などのハードウェアであったり，ロック，データオブジェクトなどのソフトウェアであったりする。 スケジュールは，1.3.1で示すとおりに，適時性基準などの基準に関して最適となることが意図されている。
一方，"ディスパッチング"(dispatching)とは，現在最も適格な競合実体にアクセスを認める過程とする。 "適格性"(eligibility)は，スケジュールにおける実体の位置によって示されるか，スケジュールが無い場合には，例えば，優先度又は期限という，一つ以上の適格性パラメタの値によって示される。 前者の場合は，スケジュールの先頭の実体が，そのスケジュールの中のすべての実体の中で最高の適格性をもつ。 後者の場合は，最高の優先度又は最も早い期限をもつ実体が，資源にアクセスする準備のできているすべての実体の中で，最高の適格性をもつ。 簡単のために，ここでは，より一般的な半順序ではなく，全順序を仮定している。
優先度又は期限のような適格性パラメタは，それぞれ，優先度又は期限の順序で，スケジュールを生成するために使用できる。 適格性パラメタのその他の利用法として，スケジュールされていない競合実体のヒープからの(最高の優先度又は最も早い期限に従った)ディスパッチングがある。 これを，"ディスパッチング規則"(dispatching rule)を使用するという。 これは，実時間システム及び実時間オペレーティングシステムでは，より一般的な適格性パラメタの利用法である。 優先度及び期限のような一般的な適格性パラメタは，スケジューリング又はディスパッチング規則のいずれかに使用できる。 "最も早い期限を最初に"(earliest deadline first)というアルゴリズムは，両方のアプローチで用いられることが多い。 スケジューリング及びディスパッチング規則の両方は，次に示すとおりに，常にある基準を最適化しようと努める。
スケジューリングをとるかデスパッチング規則をとるかの選択は，アプリケーション固有の基準に基づいて行うのがよい。 両方ともに，厳密な期限をすべて満たすなどの基準に対して最適化が可能だが，スケジューリングだけが，"積算有用度"(accrued utility)を最大化するなどの他の基準に対して最適化できる。 ディスパッチング規則は，最も適格性の高い競合実体だけを考慮するという意味で，"どん欲"(greedy)である。 スケジューリングは，実体が共有資源へアクセスする順番を最適化する効果を明示的に考慮してもよいという意味で，必ずしも，どん欲ではない。(優先度順スケジューリングは，どん欲であるが。) 例えば，ディスパッチング規則は，プロセサ時間をT単位消費し，8単位の有用度が得られる一つのタスクを選ぶが，合計してプロセサ時間を同じT単位消費する二つのタスクが，それぞれの有用度が5単位で，有用度の合計が10単位の場合，これらのタスクを選ばない。 後者の方が，積算有用度及び単位時間有用度は高い。 積算有用度を最大化するスケジューリングアルゴリズムは，ディスパッチ規則とは反対の選択をする。
意見 スケジューリングの概念は，実時間計算の実践において誤解されていることが多い。 開発者は，優先度，率又は期限のそれぞれに基づくディスパッチングのようなディスパッチング規則を参照する場合に，スケジューリングと言っていることが多い。 しかし，ディスパッチ規則を使うことが開発者の必要性に対して適切な決定かどうかとは関係ないことだが，スケジュールは生成していない。 さらに，ディスパッチング規則は，それが何の基準なのか，何の基準に対して最適ではないのかを，ほとんど又は全く理解しないで使用されていることが多い。 他の一般的に混同されていることに，OSディスパッチャをスケジューラと呼んでいることがある。 OSディスパッチャは，スケジュールが提供されている場合にはスケジュールからディスパッチを行い，そうでない場合にはスケジュールされていないヒープからディスパッチを行なう。通常，システムは，スケジュール対象となる実体と，スケジュール対象ではない実体とを含む。
計算システムには，通常，"スケジュール対象実体"(schedulable entity)及び"スケジュール対象外実体"(non-schedulable entity)の両方が含まれる。 スケジュール対象実体は，アプリケーション及びシステムソフトウェアの両方における，スレッド，タスク，プロセスなどで，スケジューラによってスケジュールされる。 スケジューラは，オペレーティングシステムのようなシステムソフトウェアの一部か，オフラインの人間又はプログラムとする。 スケジュール対象外実体は，ほとんどがシステムソフトウェアの中にあって，割込みハンドラ，オペレーティングシステム命令，パケットレベルでのネットワーク通信サービス，又はオペレーティングシステムのスケジューラを含んでいる。 スケジュール対象外実体は，連続的，周期的又はイベント応答的に実行できる。 その適時性は，システム設計及び実装に任されている。
実時間計算の開発者，すなわち，実時間OS作成者及び利用者は，主に，例えば，割込み応答時間などのスケジュール対象外実体の観点から適時性に焦点を当てている。 一方，実時間計算の原理及び理論は，主に，例えば，タスクの完了期限に間に合うなどの，スケジュール対象実体の観点から適時性に焦点を当てている。
意見 スケジュール対象実体とスケジュール対象外実体とを区別することには，二つの基本的な理由がある。 第1のより明らかな理由は，スケジュール対象実体及びスケジュール対象外実体の両方が存在するという現実を明らかにし，それを調整することにある。 第2のそれほど明らかではない理由は，この区別が，実時間計算分野における開発者と研究者との間の大きい溝の基本的な原因となっていることにある。 ユーザ及びベンダといった実時間計算の開発者は，通常，主にスケジュール対象外実体のことを考える。 例えば，OSサービス遅延及びディスパッチ遅延についての厳密な上限の観点から"厳密な実時間"について考える。 OSサービスは呼び出されたときに実行され，割込みサービスルーチンは，少なくともその"直接の"(immediate)又は"下位の"(lower)部分は，割込みが起こったときに実行される。 実時間計算の研究者は，通常，主にスケジュール対象実体に関して考える。 例えば，タスクを完了するために，すべての厳密な期限を常に満たすという観点から"厳密な実時間"を考える。
実時間計算に含まれる"適時性規定"(Timeliness Specification)には，"個別的"(individual)及び"集団的"(collective)の二つのレベルが存在する。 個別的実体，すなわち，スレッドなどのスケジュール対象実体及び割込みルーチンなどのスケジュール対象外実体は，それ自体の適時性規定をもってよい。 実体の集合は，集団的な適時性規定をもってよい。
意見 実時間計算の開発者のコミュニティは，スケジュール対象外実体の観点から考えているが，これらの実体が，個別的及び集団的な適時性規定をもつとは，通常考えていない。 この規定をはっきりと認識することは，理論及び実践の両面において利点がある。 理論の面では，スケジュール対象実体及びスケジュール対象外実体の両方に，同じ概念及び用語を用いることができる。 実践の面では，設計者及び実装者が，スケジュール対象外実体の適時性について，明示的及び系統的に考えられるようになる。スケジュール対象実体及びスケジュール対象外実体は，異なるスタイルの適時性規定をもつ。 スケジュール対象実体の適時性規定は，通常は応用環境の物理的な性質から導出され，オンライン又はオフラインのスケジューラに提供されるパラメタとなる。 一方，スケジュール対象外実体の適時性規定は，例えばネットワーク特性などの計算システムそれ自体に要求される特性に基づいたり，又は最小遅延をもつという一般的な目的に基づくことが多い。 したがって，スケジュール対象外実体の適時性規定はパラメタではなく，むしろ，特定の応用にかかわらず，通常は，システムの中に設計され実装されている。
スレッドなどのスケジュール対象実体に対する適時性規定の第1レベルは，一つのスケジュール対象実体が，一つ以上の完了時間制約(例えば期限)をもってもよいこととする。 適時性規定の第2レベルは，集団的適時性の最適化及びその集団的適時性の予測可能性の最適化を求める方策に従って，スレッドなどの現在実行可能な集合がスケジュールされることとする。 集団的適時性の例には，すべての期限に間に合う，平均遅滞度を最小化する，などがある。
意見 期限などの時間制約をもつスレッドがシステムに複数個存在する場合，各スレッドがそのスレッドの期限を満たさなければならないという要件は，すべてのスレッドがそれらの期限を満たさなければならないという要件と等価とする。 後者の要件を"集団的スケジュール最適化基準"(collective scheduling optimization criterion)と呼ぶ。 しかし，すべての期限を満たすということは，多くの可能なスケジュール最適化基準のうちのただ一つに過ぎない。 他に，期限に間に合わなかった回数を最小化する，及び平均遅滞度を最小化するという二つの一般的な基準がある。 個々のスレッドの適時性によって表現できるすべてのスケジューリング最適化基準は，その集団的適時性を用いて表現できる。 ただし，この逆は真ではない。
"完了時間制約"(completion time constraint)は，スレッドの実行箇所の一部分(多くの場合は全体)に適用される論理述語とする。 この部分を，時間制約の"範囲"(scope)と呼ぶ。 完了時間制約の最も一般的な例は，期限である。 完了時間制約は，通常，応用の論理の一部であって，典型的には，応用の物理的性質から導出される。
意見 完了時間制約は，明らかに時間制約に基づくスケジューリングに対して必要であって，恐らくあまり明らかではないが，十分でもある。 通常，スレッドの実行は，外部割込み，先行制約の充足，資源競合の解消，時間切れなどのイベントによって開始される。 スレッドは，このイベントによって，完了時間制約を含めたスレッドの適格性に従ってスケジュール可能となる。 もちろん，最小の必要概念しかもたない適時性モデルは，ユーザが好むシステム観から見てより分かりやすいより最小ではない適時性モデルと比べて，本質的に有用というわけではない。 そこで，明示的なスレッド開始時間制約はこのモデルに存在しないが，追加は可能である。最も一般的な実施例は，一つのスレッド(又はタスク)を，その実行の全体に対して一つの時間制約をもつと設計することである。 言い換えれば，スレッド全体が一つの期限をもつということである。 このプログラミングスタイルは，非常に制限的となる。 その理由は，一つのスレッドとして明示されるある活動が，完了時間制約をもつ活動及びもたない活動の両方から構成される混合活動を実行することが，アプリケーションの観点からは自然な場合が多いためである。 このスレッドを，個々の時間制約に対応して又は時間制約が無いことに対応して，複数のスレッドに分割することは，状況を複雑にする人為的で歴史的な加工といえるが，個々のスレッドに対する任意の時間制約範囲を調整できないスケジューラ(通常はオペレーティングシステム)には必要とされるものである。
期限は，次の完了時間制約とする。
| a) | スレッドが期限範囲を通過することの適時性が，期限時間になる前にスレッドの実行点が期限範囲の終端に到達するかどうかに依存することを規定する。 到達する場合は，期限は満足されているとする。 |
意見 実時間計算領域においてよく知られた誤解とは逆に，期限それ自体は，適時性が期限に間に合うかどうかに何らかの点で関係していることを除けば，本質的な意味をもたない。 これは，50年間のスケジューリングの理論及び実践を通じて使用されたとおりである。 付加的な意味は，実時間計算の文脈では，"厳密な"又は"厳密でない"という修飾子によって与えられ，その他の(正しくは，すべての)文脈では，スケジューリング最適化基準によって与えられる。
"厳密な期限"(hard deadline)は，次の完了時間制約とする。
| a) | 期限が満足される場合は，すなわち，期限時間になる前にスレッドの実行点が期限範囲の終端に到達する場合は，スレッド実行の時間制約される部分が適時である。 |
| b) | 満足されない場合は，スレッド実行のその部分は，適時ではない。 |
意見 "厳密な"(hard)が"期限"に付加する意味は，適時性と期限に間に合うこととの関係が"適時に"(timely)又は"適時でない"(untimely)ということであるが，"厳密な期限"は，それ以上の意味をもつと誤解されることが多い。 しかし，厳密な期限を満たさないということの重要性は，スケジューリング最適化基準によって規定される。 つまり，システムが正常に動作するためには，すべての厳密な期限が満たされなければならない，ということが極めて頻繁に生じる。
"厳密でない期限"(soft deadline)は，次の完了時間制約とする。 したがって，厳密な期限は，厳密でない期限の特別な場合である。
| a) | 期限が満足される場合は，すなわち，期限時間になる前にスレッドの実行点が期限範囲の終端に到達する場合は，スレッド実行の時間制約される部分がより適時である。 |
| b) | 満足されない場合は，スレッド実行のその部分は，あまり適時ではない。 |
意見
"厳密でない"(soft)が"期限"に付加する意味は，適時性と期限に間に合うこととの関係が"より適時である"(more timely)又は"あまり適時でない"(less timely)ということである。
そこで，厳密な期限は，厳密でない期限の特殊な場合であり，"より適時である"及び"あまり適時でない"が二つの値，すなわち，"適時である"及び"適時でない"となる。
厳密でない実時間計算の文脈及び一般的なスケジューリングの文脈では，"より適時である"及び"あまり適時でない"は，通常，"遅進度"(lateness，完了時間から期限を引いたもの)又は"遅滞度"(tardness，max{0,遅進度}のこと)で計測される。
"厳密でない期限は, 厳密でない時間制約を単一の区間(the unit range)に限定した特殊な場合である。 一方，厳密な期限は，厳密でない期間を二つの値(binary-valued)に限定した特殊な場合である。 スレッド実行のタイミングとそのシステムの有用度との間に何の関係も無いスレッドは，非実時間スレッドとする。
意見 期限は，完了時間制約のクラスの一つでしかない。 すなわち，厳密でない期限は，厳密でない時間制約を二つの値に限定した特別な場合とする。 さらに，ここで示したとおり，厳密な期限は，厳密でない期限を一つの値に限定した特別な場合とする。 遅進度は，完了時間と有用度との間の線形な関係とする。 関数として見れば，重み付け無しの遅進度は，傾きが-1で，値域が{−期限, 無限大}の直線となる。 一般に，有用度との関係は，任意であってよい。 例えば，スレッドはより後に完了するほうが望ましいということを反映すれば，有用度は，完了時間が増加するにつれて何らかの形式で増加するかもしれない。 例えば，衛星通信では，衛星が地平線から十分に上るにつれて，ビットエラー率が低下する。 有用度は，完了時間のある範囲の間では一定のままかもしれない。 例えば，完了時間が厳密な期限より前だった場合は有用度を一定とするかもしれない。 有用度は，アプリケーション又は状況に固有な方法で減少するかもしれない。 厳密ではない期限の後では，線形で減少することが多い。"非実時間"(Non-real-time)は，ここでは"実時間"がそうでないように，基本概念でも基本用語でもない。 この標準情報(TR)での概念及び用語は，"実時間性"が二値的ではなく連続であるという事実を慎重に反映している。
実時間計算でのスケジュール対象実体に対する適時性規定の第2レベルは，"集団的な適時性の最適化基準"(collective timeliness optimization criterion)とする。 これは，時間制約をもつ複数スレッドをスケジュールするための基礎となる適時性の二つの次元を規定する。 すなわち，"集団的な適時性の最適性"(collective timeliness optimality)及び集団的な適時性の最適性の予測可能性である。 通常，スケジューリング方策における最適化基準は，相対的重要度，比例分配，優先度制約及び資源依存性という非適時性要素も含む。
この文脈で使用されているとおり，最適性とは，スケジューリング方策の最適化基準のうちの適時性要素に関するあるスケジュールの価値を示す。 すべての可能なスケジュールは，この価値の尺度に従った最適性の値をもつ。 厳密な実時間スケジューリングは，その最適化基準としてただ一つの適時性要素，すなわち，すべての厳密な期限を常に満足する，をもつ。 これは，最大の最適性だけを受理可能と規定している。 厳密でない実時間スケジューリングは，スケジューリング最適化基準における他のすべての可能な適時性要素を含んでいる。 非常にありふれた例として，間に合わなかった期限の個数の最小化及び平均遅滞度の最小化がある。 一般に，厳密でない実時間システムでは，アプリケーションと計算システムとのダイナミックスなどの状況によって，あるスレッドに対しては，部分最適なスケジュール及び部分最適な適時性をもつことが強制される。 どの最適性の値が受理可能か，したがって，どのスケジュールが受理可能かの決定は，アプリケーション固有とする。 実時間計算においては，最適性の値の予測可能性は，一般に，値それ自体と同じ程度に重要となる。
意見 個別の時間制約をもつ実行可能スレッドの集合は，一般には，異なる系列で多重に実行するようにスケジュールできる。 アプリケーション及びシステムは，ほとんど常に，ある可能なスケジュールを他より好む。 この好みの基準を，"スケジューリング最適化基準"(scheduling optimization criterion)と呼ぶ。 集団的な(及びしたがって個別の)スレッド適時性は，この基準の中の一因子となる。 この基準を使用するスケジューリングアルゴリズムが用いられる。 スケジューリングは，一般に，特にほとんどすべての興味深いスケジュール問題は，NP困難となる。 すなわち，スケジュールされる実体の個数に対して指数的に増加する時間が必要となる。 したがって，最適のスケジュールは，通例というよりもむしろ例外である。 厳密な実時間スケジューリングは，その幸運な例外の一つである。 前提条件が満足される場合，すべての厳密な期限を満たす最適性基準の適時性因子を満足するスケジュールを生成する単純なアルゴリズムが存在する。 この場合，それらスケジュールのいずれもが受理可能とする。 厳密でない実時間スケジューリングは，厳密な実時間の前提条件が満足されない場合，又は厳密でない期限若しくは一般の時間制約がより適切な場合に，必要とされる。 厳密でない実時間スケジューリングの最適性基準，及びスケジューリングアルゴリズムは，厳密な実時間のものよりははるかに複雑だが，より広い範囲の適時性要件，並びにアプリケーション及びシステムの条件に対して適用可能である。
特性は，前もってわかる程度に予測できる。 予測可能性のスケールの一端は"確定性"(determinism)で，特性について前もって正確に分かっているという意味とする。 他の一端は"最大エントロピー"(maximum entropy)で，その特性について前もって何も分かっていないという意味とする。 厳密な実時間システムを特別な場合として含む確率的システムにおいて，予測可能性を測る一つの方法に，変動係数Cvがある。 予測可能性の最も大きい端は，確定的分布(Cv＝0)であって，予測可能性の最も小さい端は，指数分布の極端な混合(Cv＝∞)である。
意見 適時性の予測可能性は，実時間システムの最も根本的な特性である。 それでいて，予測可能性は，実時間計算の実践において，そして実時間計算の理論においてさえ，最も誤解されている概念の一つである。 この誤解の中で最も多いものは，用語の"確定的"と"予測可能"とを交換可能として使用すること，及びそれらの用語を間違って個々に使用すること，の二つである。 これらの概念及び用語を，実時間計算にとって十分な程度に正確及び有用に理解するために，物理学又は確率論を持ち出す必要はない。
最も重要な適時性の予測可能性は，通常，集団的適時性の最適性の予測可能性であり，スレッド自体の時間制約に関する個々のスレッドの完了の予測可能性ではない。 言い換えれば，最も重要なのは，すべての期限を満たすこと，期限に間に合わない回数を最小化することなどのシステム全体としての性能である。 原則として，特定の実体のそれぞれの予測可能性は，集団的な適時性の最適性基準の一部として規定することができる。 例えば，スレッドTa及びTbの期限を確定的に間に合わせたり，その他のすべてのスレッドの期限の平均遅滞度を最小化するなどである。 実際，最適性基準及びスケジューリングアルゴリズムにとって，個々の実体を区別するよりも，厳密な時間制約と厳密でない時間制約とを区別したり，又は相対的な重要性を考慮する方が，より単純となる。
意見 特定の一つ以上の実体の適時性が予測可能であるかを考えるのが自然なことが多い。 例えば，期限に間に合う確率は，先行するスレッドの遅進度に恐らく依存するので，異なるスレッドに対して別々の値を望んでもよい。 しかし，スケジューリング理論は，ある基準に従ってその集団的な適時性が最適となるように，すべての実体の実行をスケジュールするという，より扱いやすい目標に主な焦点を置いている。 このように限定しても，ほとんどの興味深い問題は，扱いにくいままである。 それにも拘わらず，システム全体の集団的な適時性は，規定するのは複雑なことが多いが，理想的な尺度である。 最も単純な実時間システムを除くすべてにおいて，発見的な手法が必要である。
集団的な適時性の二つの次元，最適性及びその予測可能性，は直交しており，アプリケーション固有の基準に基づいて，互いにトレードオフを行わなければならないことが一般的である。 例えば，より良い最適性(例えば，より低い平均遅滞度)を生じるがより悪い(より高い)変動係数をもつスケジュールと，より悪い最適性(例えば，より高い平均遅滞度)を生じるがより良い(より小さい)変動係数をもつ別のスケジュールとのいずれかを選択する必要があるかもしれない。 厳密な実時間は，このトレードオフが必要でない特別な場合である。
意見 これは，理論上は自明であり，実践上でも明らかに正しい。
スケジュール対象外実体の適時性規定は，スケジュール対象実体の適時性規定にちょうど対応する。 厳密な期限及び厳密でない期限は，厳密な上限及び厳密でない上限で置き換わる。 集団的な適時性は，設計及び実装の時点の責任となる点を除いて，スケジュール対象実体と同じである。 適時性の予測性も，スケジュール対象実体と同じである。
意見 スケジュール対象外実体の適時性規定が重要である理由は，これらの実体が，スケジュール対象実体と同様に重要となり得る機能を実行すること，スケジューリングが考慮できない時間及び資源を消費することの二つである。 上限は，スケジュール対象外実体の適時性を評価し，スケジュール対象実体の適時性に対する影響を説明するための手段を提供する。 実時間計算の実践では，スケジュール対象外実体の遅進度(特に，割込み応答時間及びOSサービス時間)の上限は，それが望ましいかどうかはともかく，適時性の主要な尺度である。 しかし，実践においては，スケジュール対象実体の適時性特性に相当する特性をスケジュール対象外実体がもってもよいと認識するまで至っていない。
スケジュール対象外実体の完了時間制約には，次のものがある。
| a) | 実行の遅進度(実行期間)に対する厳密な上限及び厳密でない上限。 これらは，スケジュール対象実体の厳密な期限及び厳密でない期限に対応する。 |
| b) | 遅進度に対する一般的な時間制約。 これらは，スケジュール対象実体における一般的な時間制約に対応する。 |
この文脈における"上限"(upper bound)は，次の完了時間制約とする。
| a) | スケジュール対象外実体が上限の範囲を通過することの適時性は，上限時間になる前に実体の実行点が期限範囲の終端に到達するかどうかに依存するということを規定する。 到達する場合は，上限は満足されているとする。 |
この文脈における"厳密な上限"(hard upper bound)は，次の完了時間制約とする。
| a) | 上限が満足される場合は，すなわち，上限時間になる前にスケジュール対象外実体の実行点が期限範囲の終端に到達する場合は，実体の実行の時間制約される部分が適時である。 |
| b) | 到達しない場合は，適時ではない。 |
この文脈における"厳密でない上限"(soft upper bound)は，次の完了時間制約とする。
| a) | 上限が満足される場合は，すなわち，上限時間になる前にスケジュール対象外実体の実行点が期限範囲の終端に到達する場合は，実体の実行の時間制約される部分がより適時である。 |
| b) | 到達しない場合は，あまり適時ではない。 |
"厳密でない(一般)時間制約"[soft (general) time constraint]は，スケジュール対象外実体の実行点がその時間制約される範囲の終端に到達する時間と，その時間のシステムに対する有用度との間の何らかの関係とする。 厳密でない上限は，厳密でない時間制約を二つの値に限定した特殊な場合とする。 一方，厳密な上限は，厳密でない時間制約を一つの値に限定した特殊な場合とする。
スケジュール対象外実体に対する集団的な適時性の最適性は，最適性を求めることがシステム及びアプリケーションの設計及び実装の過程での責任となるという点を除いて，スケジュール対象実体に対する集団的な適時性の最適性に類似している。 スケジュール対象外実体に対する集団的な適時性の最適性基準は，スケジュール対象実体に対する集団的な適時性の最適性基準と同様に扱うことができる。 例えば，すべての厳密な上限を満たすこと，相対的重要性に従って平均遅滞度を最小化することなどを用いることができる。
スケジュール対象外実体に対する適時性の最適性の予測可能性は，スケジュール対象実体に対するものと同様とする。
"厳密な実時間"(hard real-time)とは，次の場合とする。
| a) | スケジュール対象実体に対しては，幾つかの厳密な期限が時間制約であり，スケジューリング最適性基準の適時性に対する要素がすべての厳密な期限を常に満たす。 なお，任意の厳密でない時間制約に適用される付加的な適時性に対する要素があってもよい。 |
| b) | スケジュール対象外実体に対しては，厳密な上限が幾つかあり，システムは，すべての厳密な上限が常に満足されるように設計され実装されているとする。 なお，厳密でない上限をもつスケジュール対象外実体があってもよい。 |
意見 厳密な実時間は，実践において誤解されていることが多い実時間計算の基本的な概念の一つである。 開発者は，通常は基本的にスケジュール対象外実体で(厳密な実時間を)考えるが，実時間計算の理論家は，通常はスケジュール対象実体だけで考える。 有効な定義は，集団的な完了適時性だけでは与えられず，スケジュール対象実体及びスケジュール対象外実体の両方で与えられなければならない。
"厳密でない実時間"(soft real-time)とは，厳密な実時間以外のすべての場合を表現する。 つまり，厳密でない実時間は一般的な場合とし，厳密な実時間は特別な場合とする。 時間制約は，古典的な遅進度関数のように，厳密でないとする。 ただし，これには特別な場合として厳密な期限が含まれてもよい。 期限に間に合わない回数の最小化，平均遅滞度の最小化，発生した有用度の最大化などの，いかなるスケジューリング最適性基準を使用してもよい。 ただし，これには特別な場合として厳密な実時間が含まれてもよい。 スケジュール最適性の予測可能性(したがってスレッド適時性)は，一般に，"準最適"(sub-optimal)とするが，確定的であってもよい。 ただし，これには特別な場合として厳密な実時間の場合も含まれてもよいが，それに限定されない。 上限は厳密でないとし，スケジュール対象外実体に対する適時性の予測可能性は，一般に準最適とする。
意見 厳密でない実時間は，実時間計算の理論家でさえ，"厳密な実時間ではない"という同義反復のままにしておく傾向にあるため，厳密な実時間よりも正しく定義されていない。 厳密でない実時間は，スケジューリング理論において正確に定義された対応概念に直接に対応する。
資源管理は，スレッドなどのスケジュール対象実体の時間制約(例えば，期限)を明示的に用いるという程度に実時間とする。 実時間の資源管理は，プログラマによって実行前に，又は計算システムによって実行時に，行なうことができる。
意見 資源管理が実時間である程度を考えるために，つまり，実時間計算の概念及び用語に矛盾しない資源管理を考えるために，定性的基準をもつことは有用である。 しかし，定量的尺度をもつことは有用とは思えない。
要件定義グループは，次のJavaの特長が，実時間要件のための基礎を与え，実時間性を必要とする分野でJavaを使用する動機になると考える。
要件定義グループは，Javaプログラム言語で記述され，様々なJavaプラットフォームで実行される実時間アプリケーションが必要とする実時間機能のための領域横断的な要件を開発するために，次の三つの指針を使用した。
| a) |
RTJ(1)の設計は，最適な効率又は性能を犠牲にしても，使いやすさを改善するという妥協を行ってもよい。
注1 "RTJ"は，0.2で定義したとおり，Javaプラットフォームの実時間拡張を通して提供される機能及びサービスの両方を特定するために使用する。 |
| b) | RTJは，数十年，場合によっては数世紀にも渡る存続期間をもつソフトウェアの作成をサポートするほうがよい。 |
| c) | RTJの要件は，実時間システムの実用化状況を考慮することによって実用的であると同時に，最新技術を進展させる道筋及び方向を提供することによって将来展望を与えることを目指す。 |
参考 実時間ソフトウェアの現在の開発では，商用又は専用の実時間オペレーティングシステムとCプログラム言語とを組み合わせて使うことが支配的となっている。 要件定義グループは，次の実時間オペレーティングシステムサービスが重要であると認識している。
1) 固定優先度順スケジューリング及びラウンドロビンスケジューリングのサポート。 2) "優先度継承"(priority inheritance)又は"優先度の最高限度"(priority ceiling)のような，優先順位の逆転を回避するプロトコルをもつ相互排他ロック機構。 3) セマフォなどによって提供されるタスク間同期機能。 4) 割込みハンドラ及びデバイスドライバを記述できること。 5) 割込み許可，割込み禁止，優先度付けなど割込みを管理できること。 6) 実行中のタスクをタイムアウトできること，又はそうでない場合は異常終了できること。 実時間オペレーティングシステムの市場では，技術製品の重要な差別化は，次の点にある。
1) 小さいメモリ使用量。 2) 短い割込み応答待ち時間。 3) 異なる汎用オペレーティングシステムサービスへの対応。 4) クロス開発ツール。 これに対応して，現在商業的に成功している実時間オペレーティングシステムは，それぞれ次の構成をもっている。
1) 10KBより小さいものから数MBの範囲のサイズをもつ。 2) 数10μs単位で計測される応答待ち時間を提供する。 3) グラフィクス応用，ネットワークソケット，並びにファイル及びデバイス入出力のためのライブラリを含む。 4) 完全対応のシンボリックデバッガ及び実行性能モニタツールを提供する。 実時間システムの領域が広がり，洗練化が進むにつれて，最新技術が進展する可能性を考慮に入れるべきである。 要件定義グループが認め，評価している可能性には，次がある。
1) 実行時間及びスケジュール可能性の解析の自動化サポート。 2) 独立した実時間ソフトウェア構成要素が資源の必要性を見定め，必要な資源の折衝を可能とするためのサポート。 一般に，最新技術によって，移植性のある実時間ソフトウェア構成要素の開発及び広範囲の利用が可能になると予想される。
応用の現状との整合性を考慮すると，基礎となる実時間Java規定は，実時間オペレーティングシステムの能力のうち，次の最小部分を可能とする機構を提供しなければならない。
1) 固定優先度順スケジューリング及びラウンドロビンスケジューリングのサポート。 2) 優先順位の逆転を回避プロトコルをもつ相互排他ロック機構。 3) タスク間同期機能。 4) 割込みハンドラ及びデバイスドライバを記述できること。 5) コードセグメントとハードウェア割込みとを関連付けできること。 例えば，ベクタテーブルへコードセグメントをフックすること，割込みサービススレッドにコードセグメントを包み込むこと，がある。 6) 実行中タスクのタイムアウト，又はそうでない場合は異常終了ができること。 実時間プロファイルは，次に特徴を示す特定の実時間構成要素が要件の基本一覧に存在しない場合，可能な範囲で，その要素が特に必要なことを示すことが望ましい。
1) 小さなメモリ使用量。 2) 短い割込み応答待ち時間。 3) 異なる汎用オペレーティングシステムサービスへの対応。 4) クロス開発ツール。 将来のプロファイル，及び/又は基礎若しくは既存のプロファイルの拡張は，前述したとおり，最新技術の発展をサポートすることが望ましい。
この標準情報(TR)に示す要件を必要とするアプリケーションは非常に多岐に渡るので，要件を分割し，共通のRTJコア上の幾つかのプロファイルとして実現するのがよい。 この分割の結果，プロファイルの最小の集合が得られて，ユーザの様々な要求を満せるようになることが望ましい。 各規定は，これらプロファイルの枠組みを提供するほうがよい。 RTJコアは，元となるJavaの規定とは異なり，実時間機能から構成される。 このコアは，共通的な実時間アプリケーションの要求に対応した実時間機能で構成されることが望ましい。 コア機能の可能な水準を示す方法の一つには，広く利用されている実時間オペレーティングシステムが提供する機能の共通部分の検討がある。
プロファイルは，一つの単位としてシステムに追加するのに有用な，関係する機能の集合を含むことが望ましい。 プロファイルは，必要に応じて基本となるコアの機能を強化又は制限できる。 場合によっては，プロファイルが相互に排他的なことも考えられる。 規定に基づく実装は，どのプロファイルを実装するのかを選択するのがよい。 いかなる実装でも，コアの全機能を実装しなければならない。 ただし，コアの機能を制限するプロファイルによって規定が定義されている場合は除く。 コア機能を制限する一つ又は複数のプロファイルが存在する場合には，規定は，コアの必要な部分だけからなる実装を許容しなければならない。 与えられたプロファイルをサポートすると明記された実装は，アプリケーション結合時にそのプロファイルの機能のすべて及びそれだけを使用可能としなければならない。 アプリケーション結合時の例としては，クラスが動的にロードされる場合，又はアプリケーションがROMに格納されている場合があるが，これらに限定されない。
備考 コア機能を制限するプロファイルに関しては，合意が得られなかった。
実時間機能のコアは，プロファイルが強化及び/又は制限するように確立されなければならない。
可能なプロファイルの例の幾つかを，次に示す。
| a) | 安全性最優先。 |
| b) | 高可用性及び耐故障性。 |
| c) | 短い遅延時間。 |
| d) | 時間制限スケジューリング，優先度順スケジューリング，ラウンドロビンスケジューリング，又はスケジューリングなし。 |
| e) | 動的なロードを行わない。 |
| f) | 必要最小限。 |
| g) | 分散型実時間。 |
備考 特に断りがない限り，要件定義グループは，次の要件及び派生要件について合意に達している。
規定には，利用可能なプロファイルの参照及び発見の枠組みが存在しなければならない。 この枠組みには，例えば，プロファイルの存在，プロファイルの列挙，ロードするためのプロファイルの利用可能性などがあり，恐らく版管理も考えられる。
提供されるごみ集めは，上限をもつ中断遅延をもたなければならない。 この中断遅延は，優先度の高いスレッドが実行可能になったときにごみ集め活動を中断させるために要する時間とする。 規定は，中断によって課される制限を明確に定義しなければならない。 これには，例えば，中断タスクがメモリを割り付けられるかどうか，中断タスクが既存のオブジェクトを参照できるかどうかなどがある。
意見 ごみ集め活動は，優先度付き中断スケジューリング環境における他の処理と同様に中断される必要がある。 妥当な実時間スケジュールを作成するためには，ごみ集めの中断遅延時間には上限がなければならない。ごみ集めを中断するタイミングによっては，ごみ集め機構管理下でのヒープの状態に不整合が生じるかもしれない。 したがって，中断実時間スレッドは，そのヒープに作用できないことがある。
Javaでは，動的なメモリ解放が仮定されている。 ある特定のアプリケーションが動的なメモリ管理を必要とする場合，ごみ集めは適切な手法になる。 しかし，多くの実時間システム，特に厳密な実時間システムでは，動的なメモリ管理は要求されず，そのための領域的及び時間的な負荷は不要となる。 動的なメモリ管理を一切必要としない実時間Javaアプリケーションを作成できる。 さらに，動的なメモリ管理が存在する短い遅延時間の実時間Javaアプリケーションを作成することも可能だが，優先度が高く遅延時間の短いイベントには動的なメモリ管理は必要ない。 したがって，ごみ集め機構の中断遅延時間の上限が必要となる。
実時間スレッドによって使用されると予想される機能(言語及びライブラリ)に対して，その機能に必要なメモリ資源の厳密な上限が，実行時以前に定量化できなければならない。 例えば，特定の型のオブジェクトを表現するために必要なメモリ量，特定のメソッドを起動することによって割り付けられるメモリ量などが定量化できなければならない。
意見 この要件は，以降で示す目標8(実時間Javaは資源を予約できることが望ましく，資源を計画的に割り付けられることが望ましい。 )に結び付く。 この要件は，特定のアプリケーションにメモリをあらかじめ割り付け，ごみ集めを先に実行したい設計者にとって特に重要となる。
規定は，実時間スレッドによって使用可能な機能の集合を明確に識別しなければならない。 これらのスレッドに課される制限は，必ずしもメモリ割付け，例えば，オブジェクトの活性を変えるポインタ代入，だけの結果とは限らない。
意見 割り込まれたシステムの状態と干渉しないために，実時間スレッドの振る舞いの制限が必要になることがある。 例えば，ごみ集め機構が中断されるタイミングによっては，ごみ集め機構管理下のヒープの状態に不整合が生じるかもしれない。 したがって，中断実時間スレッドはそのヒープに作用できないことがある。
RTJは，オブジェクトを，いつ終了化するか若しくは回収するか，又はそもそも終了化するのか回収するのか，に関する制限を要求してはならない。
意見 そのような制限は，Java言語規定に矛盾する。
RTJ内で，アプリケーションにGCの負荷がある場合は，これを定量化しなければならない。
意見 ごみ集め活動は，実時間システムの他の処理と同様に，スケジューリングされなければならない。 GCの負荷を定量化できない場合は，有効な実時間スケジュールを構成できない。
RTJ規定は，既存の規格文書で現在入手可能な水準と同程度に詳細に，実時間Javaスレッド間の関係を定義しなければならない。 規定の最小限の要件の例としては，POSIX 1003.1Bがある。 これら関係の例には，スレッドのスケジューリング，待ち行列の順序付け及び優先順位逆転回避方策が含まれる。
RTJ規定は，JavaとJava以外のタスクとの間の通信及び同期を可能とするためのAPIを含まなければならない。
RTJ規定は，内部及び外部の両方の非同期イベント処理を含むものとする。 そのモデルは，それらイベントに応答してJavaコードを実行するための機構をサポートしなければならない。 この機構は，既存のJavaの機構(例えば，wait又はnotify)と適合しなければならない。
備考 個々のスレッドを対象とした一般的な同期イベントが必要かどうかについては，合意が得られていない。
RTJ規定は，何らかのスレッドの非同期な終了処理を含むものとする。 このスレッドの非同期な終了処理は，次の特性をもたなければならない。
| a) | デフォルトでは，スレッドは異常終了されることはない。 | ||||
| b) | ターゲットコードが，スレッドをどこで異常終了できるか決定する。 | ||||
| c) |
スレッドが異常終了される場合，次のことが実行される。
|
||||
| d) | 非協調的コードを異常終了する機能が提供される必要はない。 現在実行中のコードが終了処理を求めていない場合は，終了処理は保留される。 | ||||
| e) | プログラマがデータの完全性を保証できる機構が提供されなければならない。 |
RTJコアは，ブロックをしない相互排他を強制的に行うための機構を提供しなければならない。 この要件は，この結果を実現するために，実時間スレッドが割込み許可及び禁止を可能とするのが望ましいことを意味しない。
規定は，機構が非実時間スレッドにマシンの完全な制御の獲得を許可しないことを要求しなければならない。 特に，スケジューラは，非ブロック相互排他を用いて付加される可能性のあるもの以外の，実行を続けるスレッド及び割込みハンドラのディスパッチを継続実行する。 規定は，恐らくJavaの既存のセキュリティ管理機構と統合することで，システムの完全性を損ねる危険性を最小とすることに注意しなければならない。
意見 "ブロックをしない相互排他"の最初の考えは，Java命令のアトミックな列を構築する機構であった。 この機構は，ロック機構で行えないことは何もすることができない。 しかし，この機構は，基礎となるプラットフォームによってサポートされないかもしれないアトミックな命令列のための効率的な機構を，Java言語から利用可能にする。すぐに思いつく機構は，割込みをマスクすることである。 アトミックな命令列の長さが短い場合，割込みマスクは，オペレーティングシステムのコードが命令列に割込みを受けないことを保証するための標準的な方法となる。
割込みのマスクには，次の三つの問題がある。
a) 複数のプロセサがJavaスレッドを実行している場合には，割込みマスクは，十分ではない。 b) Javaがシステム状態で実行していない場合は，割込みマスク機能は使用できない。 c) 割込みマスクは，マシン全体に影響を及ぼす。 非Java割込みもマスクされる。 さらに，アトミックなセクションの持続期間を制限する要件が存在しない。 ディスパッチャにはスレッドの切替えと割込みへのサービスとを続けることが要求されるので，要件からは，割込みマスクが排除される。 これによって，これらの問題を回避できるが，課題として残っている。
可能な解は，決してブロックせず，資源がロックされておらずロックを獲得した場合だけに成功を返す，"条件付き獲得ロック"を提供することである。 これは，要件を満たすものと考えられるが，要件グループの会議においては，可能性として挙げられることが一度もなかった。 条件付きロックは，提案されている単純なアトミックな命令列の開始及び終了のモデルの代わりに，2層コミットに似た手続きを必要とすることになるだろう。
恐らく，ブロックしないと見せかけることによって，非ブロック相互排他要件を満たすことができる。
システムは，すべてのスレッドで共有される大域ロックを用いてブロックする相互排他実行を使用することができる。 実際，プロセスは，相互排他セクションを開始しようとする時にブロックするかもしれないが，そのプロセスは，その同じ瞬間に他のスレッドが非ブロック相互排他を開始した場合には，全く同じ振る舞いをすることになる。
長いアトミックなセクション，すなわち，ごみ集め，終了化子(finalizer)の実行，例外，又は他の予測困難なコードを含むことができるものは，アプリケーション全体の実時間特性にとっては致命的な問題になりかねない。 アトミックなセクションを，その実行内容及び実行時間について制限するという要求を行うのは可能だろう。 しかし，これらの制約を実現するには，恐らく，JVMの変更が必要となる。 長さ制限は，アトミックなセクションの中のコードが"分析可能"という要件に帰着されるであろう。 これは，例えば，アトミックなセクションで実行される命令の数の上限を設定できない自動化ツールを不正とする，などである。
備考 これまでの議論の経緯を考慮して，次の派生要件が合意のもとに削除されたことを明記しておく。Java言語互換なPERC処理系が使用するatomic文が行なったような，制御列の変更を生じるかもしれない非同期イベント処理が存在する場合には，RTJ規定は，データ完全性を保証するための機構を提供しなければならない。
RTJ規定は，コードが，実時間Javaスレッド又は非実時間Javaスレッドのいずれで実行されているのかを問合せ可能な機構を提供しなければならない。
RTJ規定は，実時間Javaスレッドと非実時間Javaのスレッドとの間の関係を定義しなければならない。 その規定は，実時間Javaスレッドと非実時間Javaスレッドとの間で通信及び情報共有を行うための機構を提供しなければならない。
従来のJavaソフトウェアは，非実時間タスクとして実行されなければならない。
備考 これまでの議論を考慮して，次の派生要件が合意のもとに削除されたことを明記しておく。非実時間タスクと実時間タスクとの間での情報共有を認める機能が提供されなければならない。
共有及び通信プロトコルは，ブロック遅延についての既知の厳密な上限又は予測可能性の他の形式をもたなければならない("予測可能性"の定義については，1.2.1.2.2を参照)。
RTJスレッドと他の3種類のスレッド(非実時間Java，非Java実時間及び非Java非実時間)との関係を定義しなければならない。
これらの関係には，次が含まれる。
備考 Javaの非実時間タスクの振る舞い及び非Javaタスクの振る舞いの標準化は可能ではない(これらは，どちらも実時間Java規定の範囲外である。 )ことを考えると，スレッド間の定義は正確でないことがある。
意見 実時間Javaスレッドを実行するシステムは，従来のJavaスレッド及び非Javaスレッドも実行できる。 典型的な組込み型システムでは，すべてのJavaスレッドが実時間の場合もあるが，多くは，同じハードウェアで非Javaスレッドが実行される。 さらに，より大規模なシステムでは，上記のスレッドの混在に非実時間Javaスレッドが追加されることが多い。これは，2組の関係があることを意味している。 一つは実時間規則に従わないJavaスレッドとの関係であって，もう一つは(実時間かどうかは問わない)非Javaスレッドとの関係である。
非実時間Javaスレッドとの関係は，実時間Javaスレッドとの関係に似ている(コア要件3参照)。 非実時間スレッドが，実時間スレッドに要求される特別な規則及び指針に従うことは期待できないので，非実時間スレッドは実時間スレッドが存在していても"通常どおりに"動作する必要がある。 したがって，実時間スレッドは，現在サポートされている機構を使って非実時間スレッドと通信しなければならず，現在サポートされている機構では，実時間終了時にだけ新しい振る舞いが見えるようになる。
規定は，次の項目に答えなければならない。
- 非実時間スレッドの優先度を実時間スレッドよりも高くできるか。
- 現在定義されているスレッド間の通信及び同期のすべての機構は，実時間スレッドと非実時間スレッドとの間で機能するか。
- 実時間スレッド及び非実時間スレッドが明示的ロック又は暗示的ロックに出会った場合，何が起こるか。
- スレッドがロックを保持している間に終了するとどうなるか。
コア要件4では，実時間スレッド間の相互作用のための綿密な規定が要求されている。 コア要件9では，これらの要件を，実時間スレッドによって使用されることが可能なJava機構，及びコア要件3のために必ずしも綿密に規定されていないJava機構のすべてに拡張している。
正しく振る舞う実時間スレッドがXを行わないと宣言するオプションがある。 この場合，Xの振る舞いの特性を完全に記述する必要はない。 しかし，非実時間スレッドが，実時間スレッドに対して、その同意なくYを行える場合，Yの特性は，完全に規定されなければならない。
標準Javaプラットフォームは，実時間スレッドと非実時間スレッドとの間の通信に適した機構を提供していない。 要件定義グループが選択する機構は，実時間スレッドがブロックするかしないかを制御できなくてはならないものとする。 さらに，機構は単純であって，効率的なことが望ましい。
その機構は単純なメッセージキューである必要はないが，それが最もよく適合すると考えられる。
要件定義グループは，基本実時間Java規定，将来のプロファイル，又は将来の基本規定で，適切に扱うべき13の目標を定義した。 目標の幾つかは，派生要件を伴う。 これらの要件の多くが，将来使用されることを意図している。 要件定義グループは，議論を生じ将来の革新を必要とする要件を追加した。
RTJは，システム稼働目的の実時間性の要求度に応じて，資源管理の実時間性の要求度を変化させられることが望ましい。 ここで要求度とは，例えば，厳密な実時間，時間制約をもつ厳密でない実時間，集団的な適時性の最適性基準，最適性と予測可能性とのトレードオフなどである。
RTJ規定に対するサポートは，完全なJavaプログラム言語のいかなる実装上でも可能なことが望ましい。
RTJプログラム技術が，大規模メモリ又は小規模メモリのシステム，高速又は低速のコンピュータ，単一CPU又はマルチCPUのアーキテクチャなどに応じて調整できることが望ましい。
RTJは，恐らく異なった"プロファイル"を使用して，小さい単純なシステム及び大きい複雑なシステムの両方の作成をサポートすることが望ましい。
特定の専門分野の効率及び/又は信頼性を改善するために必要な，RTJ及びRTJVMの規定の標準的な部分集合が作成されることが望ましい。
資源使用可能性及び性能特性に従って，基礎となるプラットホームにかかわらず，完全に移植可能なRTJのプログラム及び構成要素を書けることが望ましい。
ソフトウェアを新しいハードウェアプラットホームに"移植する"場合，又は新しいソフトウェア構成要素と結合する場合，人の必要な介在は，最小となることが望ましい。
RTJは，オペレーティングシステム及びハードウェアの依存性を抽象化することが望ましい。
RTJは，標準Javaセマンティクスをサポートしなければならない。
RTJ技術は，例えば，開発ツール，ライブラリなどの，非RTJ技術を最大に利用することが望ましい。
RTJ APIは，すべての言語機能に関する保証付きで，明確に定義されなければならない。
RTJは，実時間タスクと非実時間タスクとの組合せで構成された作業負荷をサポートすることが望ましい。
RTJは，実時間アプリケーション開発者が，折衝を行う構成要素の間の関係を分離できることが望ましい。
RTJは，実時間アプリケーション開発者が，実行時又はオフラインのいずれかで資源要件分析の自動化を行えるようにすることが望ましい。
RTJは，実時間アプリケーション開発者が，ソフトウェアに実時間制約を書けることが望ましい。
備考 以降の箇条の細分化に関しては，条件付きで，合意が達成された。
RTJは，消極的又は積極的な資源割付けを使用するかどうかのオプションをアプリケーション開発者に提供することが望ましい。 (未決定 − 未合意)
同一のRTJVMで，積極的及び消極的な計画的割当てを結合した作業負荷をサポートすることが望ましい。 (未決定 − 未合意)
RTJ基盤は，資源の計画的割当て及び資源の競合に関連する危険の評価及び管理を，折衝を行う構成要素に任せることが望ましい。
RTJは，アプリケーション開発者が，"広範囲な関係"を理解しなくとも，実時間要求を指定できることが望ましい。 例えば，折衝を行う構成要素は，優先度ではなく，期限及び期間を使って折衝できることが望ましい。
RTJは，Javaスレッドが利用可能な優先度とシステムで利用可能なすべての優先度との間の関係を見つけるための機構を提供しなければならない。 さらに，Java優先度とシステム優先度との間の関係が決定できる機構を供給しなければならない。 ただし，これは1回の呼出しでなくてもよい。
RTJは，資源予約を許可し，資源の計画的割当てを守らせることが望ましい。 次の資源，CPU時間，メモリ及びメモリ割付け率は，計画的割当てが可能なことが望ましい。
RTJは，次を行わなければならない。
言語及びライブラリは，メモリ使用状況を使って明確に理解されなければならない。
RTJは，保証された割付け率に対するサポートを提供しなければならない。
オブジェクトが，いつ終了化されるか，又はいつ回収されるかについて，RTJは，制限を要求してはならない。
RTJは，メモリの指定を提供することが望ましい。
優先度機構は，優先度の高い水準への設定に関係する，既存のセキュリティプロトコルを考慮に入れなければならない。
RTJは，同一スレッド上での使用を含め，"ブラックボックス"としての構成要素の使用をサポートすることが望ましい。 (未決定 − 未合意)
RTJは，折衝を行う構成要素の動的ロード及び統合をサポートすることが望ましい。
折衝を行う構成要素のコードの"危険域"(critical section)の振る舞いが局所的に分析可能な機構をサポートすることが望ましい。
RTJは，("標準"のJava機能に関してと同様に，)外部から観測可能な方法で，(通知，イベント処理及び計算を用いて，)空間的及び/又は時間的な制限を守らせる能力をサポートすることが望ましい。
実時間文脈で，既存のJava機能が，synchronized(優先順位の逆転の制限)及びwait/notify(優先度による待ち行列処理)を含めて，"正しく動作"することが望ましい。
参考 ユーザが定義した方策管理機構の"範囲"の中で生成されたスレッドは，その方策の管理下にある。 既存のスレッドクラスの優先度は，実時間優先度に対応付けられるかもしれない。
RTJは，ごみ集めが必要な場合，実時間ごみ集めを提供しなければならない。 GC実装情報は，RTJアプリケーションに見えていなければならない。 "実時間ごみ集め"の定義を参照すること。
RTJは，"ごみ"を定義する。
RTJは，GCに関係する"処理するヒント"の情報を提供することが望ましい。 この情報には，例えば，正確か又は消極的か，断片化を解消するか，などがある。 (未決定 − 未合意)
RTJは，ごみ集め技術を限定しても指定してもならない。 むしろ，実時間GCのために，すべての適切な技術のサポートを可能にすることが望ましい。
GCは，ある率で進行しなくてはならない。 その率は，"問合せ可能"及び変更可能でなければならない。
RTJ内で，GCの負荷が存在する場合，それは，アプリケーション上で定量化されなければならない。
RTJは，(ハードウェアの変更を含めて)独立して開発されたソフトウェア構成要素の，簡単で信頼性の高い統合をサポートすることが望ましい。
RTJは，Adaなどの他の言語による目標設定を(特定の考慮をもって)サポートするのに十分なほど詳細に，規定されることが望ましい。
RTJは，実時間機能をサポートするオペレーティングシステム上で実装可能なことが望ましい。