今回は、前回に引き続きMIDP 3.0のPublic Draftから、その新機能について紹介していきたい。

MIDletの並列実行をサポート

MIDP 3.0ではMIDletの並列実行のサポートが明確化される。MIDP 1.0および2.0においてもMIDletの並列実行が禁止されているわけではなかったが、明確な振る舞いについては定義されていなかった。また、アプリケーションの状態の変化を扱うための機能が提供されなかった。それに対してMIDP 3.0の実行環境では、2つ以上のMIDletの同時実行を確実にサポートしなければならないと明示されており、実行時の振る舞いも明確に規定されることになる。

まず第一に、MIDletは互いに独立して一貫した動作をしなくてはならず。そのために各アプリケーションのためのデータ領域は独立していなければならない。たとえば2つのMIDletがそれぞれ同じ名前の異なるクラスを含む場合、それぞれのアプリケーションコンテキストは明確に分けられていなければならない。また同じスイート内の異なるMIDletからひとつのクラスにアクセスするような場合にも、そのクラスの静的変数などはMIDlet毎に管理されなければならない。

エラー処理については、従来は単一のMIDletだけを考えればよかったため、何らかのエラーが発生した際にはVMのシャットダウンや再初期化などを行うことができた。しかし複数のMIDletが同時に実行されている場合には、1つのMIDletでエラーが生じたとしても、他のMIDletに極力影響を与えないようにする必要がある。

もうひとつ重要な点として、すでに実行されているMIDletの2つめのインスタンスを生成することはできないことがある。もし2つめのインスタンスを生成しようとした場合には"true"の値を持ったjavax.microedition.event.EventData.APPLICATION_RELAUNCHイベントが通知されるとのこと。

なお、スケジューリング機構についてはMIDlet 3.0実装では必須(MUST)とされてはいないが、サポートすべき推奨項目(SHOULD)に挙げられている。

セキュリティモデルの拡張

MIDP 3.0ではMIDP 2.0と同様のドメインベースのセキュリティモデルに加えて、他のJavaプラットフォームと同様のPermissionクラスを採用するとのこと。これによって、MIDP 2.0ではbooleanタイプのパーミッションのみ可能であったのに対し、3.0では単一のプロパティやリソース、関数へのアクセスが可能となる。これらのパーミッションのためのクラスは、コンフィギュレーションによって定義されたクラスか、またはそれを拡張したものを利用する。そのため、MIDP 3.0の仕様策定と並行して、CLDCのメンテナンス仕様でパーミッション関連のクラスが定義されている。

アプリケーションレベルのアクセス認証

MIDP 3.0では異なるアプリケーション間でRMSデータやLIBletの共有できたり、IMCプロトコルやイベントを利用したランタイムの通信を行うことができる。そのため、従来のようにプラットフォームレベルでのアクセス認証だけでなく、アプリケーションレベルでのアクセス認証が必要となる。そこでMIDP 3.0では、あるアプリケーションが他のアプリケーションからのアクセスをコントロールできるように、アプリケーション固有の識別子を用いたアクセス認証を行うメカニズムが用意される。これはX.509 PKIによる署名と証明書を利用したフレームワークによって実現する。

このフレームワークのために、JARのマニフェストに新たにMIDlet-Access-Authorization-n属性とMIDlet-Access-Authorization-Certificate-n-m属性が追加された (mおよびnはエントリ番号)。MIDlet-Access-Authorization-n属性には「DOMAIN」「SIGNER」「VENDER; ベンダ名」のいずれかを記載する。そしてSIGNERまたはVENDERの場合には、Access-Authorization-Certificate-n-m属性にBase64でエンコードされた署名を記載する。

あるMIDletが他のMIDletのリソースにアクセスしようとした場合にはこれらの値をチェックし、アプリケーションレベルのアクセスが許可されるかどうかを決定する。実際の署名や認証処理はX.509 PKIの仕組みを用いて行う。Public ReviewではMIDlet Suiteに署名するケースとしていくつかのシナリオが紹介されている。

クラスライブラリの拡張

MIDP 3.0ではクラスライブラリも大幅に拡張されている。代表的な例としては、アニメーション画像のフォーマットをサポートするAnimatedImageクラスや、コマンドオブジェクトを表すCommandクラス、MenuCommandクラスが追加されたことや、UIコンポーネントとしてタブペインが利用できるようになったことなどが挙げられる。これらの拡張によって、MIDPアプリケーションの表現力は大幅に向上することになる。

JSR 271の今後のスケジュールとしては、まず3月18日から24日にかけてExpert GroupeによるPublic Review投票が行われる。その後、Proposed Final Draftの策定が行われ、最終承認投票を経て最終リリースとなる。現時点で当初のスケジュールよりも大幅に予定が遅れているが、最終リリースまではまだもうしばらく時間が必要となりそうだ。