現在、Java Community Process (JCP) において、JSR 271 として MIDP 仕様の次期バージョン 3.0 についての検討が始まっています。仕様リードは Motorola、エキスパートグループには世界中の携帯電話オペレーター、端末メーカー、ソフトベンダーなど 70 社（個人含む）以上が名を連ねており、MIDP 2.0 がそうであったように、間違いなく次世代の携帯電話向けの Java プラットフォームの主流になるはずです。 ちなみに、Motrola は 2006年5月、MIDP 3.0 の RI と TCK をオープンソースにして開発を進めることを発表しました。（プロジェクトのサイト） 2007年3月現在で、公開されている Early Draft Review からわかる全貌は次の通りです。
逆に、システムレベル APIや低レベルセキュリティなどのエリアは MIDP 3.0 の対象外となっています。あくまで MIDP API はアプリケーションプログラミングにフォーカスしており、下位のシステムへのインターフェースは提供しません。同様に、サービス志向アーキテクチャに関する要求も対象外です。 以下で、MIDP 3.0 で追加・改良された機能について少し詳しく見ていきます。 アプリケーションパッケージング MIDP 3.0 では、MIDlet スイート に加えて LIBlet という共有コンポーネント向けのパッケージが導入されています。LIBlet は複数の MIDlet から利用することが可能で、単独では実行されることはありません。LIBlet は MIDlet スイートと同じように JAR ファイルにパッケージされ、クラスファイル、リソース、マニフェストファイルを含みます。また、LIBlet には、LIBlet の属性の記述された JAD ファイルが必ず関連付けられています。 MIDlet スイートや LIBlet は、他の LIBlet や標準 JSR もしくは拡張 API を使う場合には、その依存関係を明示的に宣言しなければいけません。具体的には、MIDlet スイートまたは LIBlet の JAD に、依存する LIBlet や JAR の名前、ベンダー名、バージョン、および LIBlet や JAR のハッシュ値かベンダーの証明書を記述します。 MIDP 3.0 の MIDlet スイートや LIBlet には、RMS (Record Management System) 交換フォーマットで記述されたレコードストアのデータを含むことができるようになりました。この RMS ファイルフォーマットでは、暗号化の有無を設定することができ、アプリケーションインストール時に JAD ファイルの記述に従ってインストールされます。 JADの属性は大幅に増え、アプリケーションやライブラリの細かい管理ができるようになっています。 インストール・アンインストール LIBlet のインストールは、それを必要とする MIDlet スイートのインストール時に（ユーザの確認を経て）自動的に行われます。デバイスのアプリケーション管理ソフトは、MIDlet スイートをインストールする際にパッケージの依存関係を検証し、空き容量を確認して、必要な LIBlet の取得を行います。また、依存関係が解決できない場合には、インストールは行われません。 RMS データは、JAR の中に含めることもできますが、アプリケーションのインストール時に外部から取得することもできますので、これのダウンロードも行います。 MIDlet スイートのアンインストールの時には、アプリケーション管理ソフトはデバイス内で依存関係がなくなった LIBlet を削除することができます。ユーザがどの LIBlet を削除すればどれくらいの空き容量が確保できるかということを確認できるように、アプリケーション管理ソフトは必要な情報を表示すべきとされています。 プラットフォーム MIDP 3.0 の MIDlet の実行環境は、CLDC 1.1 向けと CDC 1.1 向けの 2 つが想定されています。MIDlet は、どちらの構成で動作するかを JAD 属性で指定します。MIDlet スイートの JAD 属性「MicroEdition-Configuration」に「CLDC 1.1」と書かれている場合は、実行環境は CLDC 1.1 の振る舞いをします（セキュリティ制限も含む）。同様に、「CDC 1.1」と指定されていれば、実行環境は CDC 1.1 の振る舞いをします。たとえデバイスが CDC の実装を持っていたとしても、MIDlet スイートの属性に「CLDC 1.1」の指定があれば、実行環境は機能的に CLDC 1.1 と同一になるように振舞わなければなりません。もしこの MIDlet の要求に従うことができないのであれば、インストールは行なわれません。 MIDP 3.0 をサポートするデバイスであれば、少なくとも CLDC 1.1 はサポートします。CDC 1.1 のサポートはオプションです。CLDC と CDC ではセキュリティモデルが異なるので（sandbox モデルと fine-grained モデル）動作の違いに注意が必要です。 一つの問題として、MIDP 仕様と CDC 仕様で重複している機能をどうするか、ということが取りあげられています。例えば CLDC ではネットワーク接続に Generic Connection Framework (GCF) を使いますが、CDC では java.net.* ライブラリを使うことが推奨されています。MIDP 3.0 仕様では、現状 MIDlet 開発で広く用いられている API を使うこと、つまり上の例でいえばネットワーク接続には GCF を使うことを推奨しています。これは、CDC API をサポートする MIDP 3.0 デバイスの数は限られるため、という理由からのようです。 MIDlet の 同時実行 MIDP 2.0 以前は MIDlet の 同時実行を禁じてはいませんでしたが、同時実行した際にどのように動作すべきかについては明示しておらず、また、アプリケーションの状態の変化を扱う機能が用意されていませんでした。MIDP 3.0 では、MIDlet の 同時実行のサポートを必須とし、アプリケーションが状態の遷移を的確に扱うためのメカニズムを提供します。 同時実行をサポートする上でまず重要な指針は、他の MIDlet が同時に実行されていようがいまいが、MIDlet は一貫した動作をするべきだということです。このために、あるアプリケーションからアクセスされるデータ領域は、他のアプリケーションから独立している必要があります。同じ名前を持つ異なるクラスが、別々のアプリケーションで使われた場合には独立して扱われなければなりませんし、同一のクラスであっても別々のアプリケーションコンテキストからアクセスされた場合には、その静的変数などは別々に管理される必要があります。 エラー処理も、単一アプリケーションの実行時と異なる対応が必要になります。場合によっては、ある MIDlet のエラーによりその MIDlet を強制終了しなければならない時でも、同時に起動している MIDlet の終了は必要ないという状況もあります。例えば、NoClassDefFoundError は他の MIDlet の実行コンテキストには影響を与えるべきではありません。 スケジューリングに関しては、必須ではないものの、デバイスが実装すべき推奨ポリシーがいくつか示されています。複数 MIDlet の同時実行を可能とするために、優先度や表示されているかどうかに関わらずある程度の割合の実行時間を与えることや、ユーザーフォーカスのあるアプリケーションに多く実行時間を与えることなどです。 すでに起動している MIDlet を、同時に別インスタンスで起動することはできません。もしそのようなリクエストが発生した場合には、アプリケーションには「RELAUNCH」の値を持つ javax.microedition.event.EventData.APPLICATION_STATE イベントが通知されます。 MIDlet 間通信 複数 MIDlet の同時実行のサポートとともに、2 つの MIDlet 間のストリーム接続の機能を提供する Inter-MIDlet Communication (IMC) プロトコルが定義されています。ソケット接続と同様に、IMC ではクライアントコネクションとサーバコネクションの 2 つのタイプが提供されます。クライアントコネクションを生成する際には、MIDlet 名、ベンダ名、バージョンの組み合わせである MIDlet UID を使ってサーバを指定します。 IMC の接続は、アプリケーションレベルアクセス認証をベースにした MIDlet アイデンティティ認証のメカニズムにより、安全に確立されます。クライアント、サーバの双方で認証が可能になっています。 スクリーンセーバー MIDlet スクリーンセーバー MIDlet とは、デバイスが一定時間アイドル状態になったときに自動的に起動するアプリケーションのことです。日本の iアプリや S!アプリでいう待ち受けアプリに相当します。スクリーンセーバー MIDlet は起動後、何らかの外部イベント（ユーザー操作や一定のタイムアウト）が発生するまで動作します。MIDlet-Category 属性に ScreenSaver と指定することで、スクリーンセーバー MIDlet として動作します。動作モードには「active」モードと「setting」モードがあり、アイドル時に自動的に起動する場合には active モード、ユーザ操作により起動する場合は通常の MIDlet と同様の振る舞いをする setting モードになります。 スプラッシュスクリーン Splash-Screen-Image 属性に画像ファイルを指定しておけば、MIDlet の起動時にスプラッシュスクリーンを自動的に表示することができます。MIDlet は、スプラッシュスクリーンが表示されてからの経過時間を取得できるため、表示時間をコントロールすることが可能です。 セキュリティ ベンダーアイデンティティに基づいたアプリケーションレベルアクセス認証 MIDP 2.0 のセキュリティフレームワークでは、プラットフォームレベルでセキュリティ上重要な API や機能へのアクセスが制限されていました。ところが、MIDP 3.0 では、異なるセキュリティドメインのアプリケーション間で RMS データや LIBlet のコードの共有、IMC プロトコルやイベントを使った通信が行われます。このため、これらを安全に行うために、アプリケーションレベルでアクセス認証を行う必要性が出てきました。 あるアプリケーションが他のアプリケーションからの要求を受け個別にアクセスの管理を行うために、アプリケーションのアイデンティティを認証する仕組みが重要になります。MIDP 3.0 では X.509 PKI を用いてベンダーが MIDlet もしくは LIBlet に証明書と署名を付け、アプリケーションレベルのアクセス認証を行う新しいフレームワークが導入されています。 詳細な手順は以下の通りです。
ネットワーク コマンドとメニューコマンド MIDP 3.0 では、Displayable 上の Command オブジェクトの配置を指定するためのメソッドが追加されています。コマンドのタイプと優先度を指定する従来の「native style」に対して、MIDP 3.0 で導入された「exact placement」では画面に表示されるソフトキー、もしくは画面に表示されないキーへの直接の割り付けが可能になりました。 また、画像をラベルと共に Command として設定可能になったほか、コマンドの選択状態（Selected）と有効かどうかの状態（Enabled）の属性が追加されました。 MenuCommand は Command のサブクラスで、複数の Command を含むメニューを構築します。MenuCommand オブジェクト自体を含むこともできるため、階層的なメニューを作ることができます。 アニメーション画像フォーマットのサポート GIF アニメーションや MNG などのアニメーション画像をサポートする AnimatedImage クラスが追加されました。AnimatedImage は Image のサブクラスです。getFrame() メソッドにより任意のフレームを Image として取り出すことができます。ImageItem や List などの高レベル UI 要素で AnimatedImage が指定された場合には、（システムがサポートしていれば）システム側でアニメーションが自動的に行われます。一方、低レベルの描画メソッドに AnimatedImage が渡された場合には 1 フレーム目が静止画として描画に用いられるため、Canvas や CustomItem でアニメーションを描画するには、アプリケーション側で各フレーム画像とフレーム間のインターバルを取得して、タイマーを使用して描画をコントロールする必要があります。ペイントモード Canvas および CustomItem において、paint() の処理を規定するためのペイントモードが指定できるようになりました。ペイントモードには「不透明」か「透明」を指定します。デフォルトの「不透明」モードは MIDP 2.0 までの動作と同様で、paint() の中でアプリケーションがすべてのピクセルを更新することが仮定されるため、システム側で描画の前処理は行われません。一方、「透明」モードでは、システム側が適切な背景を描画したのちに paint() に処理が回ってくるため、アプリケーションは必要な前景だけを描画すればよいことになります。 フォームの改良 MIDP 2.0 のフォームはフローレイアウトでしたが、MIDP 3.0 ではアプリケーションがフォームレイアウトポリシーを指定することで、このデフォルトのレイアウトを置き換えることができます。表にアイテムを配置する TableLayoutPolicy が始めから用意されていますが、アプリケーションでレイアウトアルゴリズムを実装した独自のポリシーを追加することも可能です。 ユーザ操作によるアイテム間の移動（トラバース）は、ItemTraversalListener にてアプリケーションに通知させることができるようになりました。 フォームアイテム、メニューコマンドのイネーブル／ディスエーブル Display の状態、DisplayListener、外部ディスプレイのサポート、オリエンテーション フォントサポート フォントの指定を物理フォント名（Helvetica、Palatino、本明朝など）および論理フォント名（Serif、SansSerif、Monospaced など）にてできるようになりました。また、アセントやディセントなどのフォントの詳細情報が取得できるようになりました。 アプリケーションがシステムに備わっていない独自のフォントを使用したい場合、InputStream から読み込んだ TrueType ベースの OpenType フォントを使用することもできます。この場合、フォントは JAR ファイルに含めることも、サーバからダウンロードすることも可能になります。 アルファ値とブレンディングモード 描画の際の透明度を指定するアルファ値が、Graphics オブジェクトに追加されました。アルファ値は 0〜255 の 8 ビットで指定し、透明度を持った文字や線、四角形、円弧、多角形などを描画することができます。一方、drawImage や drawRGB などの画像の描画メソッドでは、画像データに含まれるアルファ値と Graphics オブジェクトのアルファ値を乗じた透明度で描画が行われます。 また、Graphics オブジェクトでは 2 つのブレンディングモード（SRC_OVER と SRC）がサポートされています。SRC_OVER モードでは、転送元ピクセルのアルファ値をもとに転送元ピクセルと転送先ピクセルがブレンドされます。一方 SRC モードでは、転送先ピクセル（アルファ値含む）は転送元ピクセルで置き換えられます。 TabbedPane のサポート 高度な文字列のレイアウトを実現する Text のサポート ストレージ MIDlet スイートおよび LIBlet 間で共有・交換可能なレコードストアが導入されたため、それに伴うアプリケーション記述ファイルの属性、API が追加されました。 MIDP 2.0 では、レコードストア内の特定の条件に合ったレコードを列挙するのに RecordComparator や RecordFilter インターフェースが使われましたが、大きなレコードストアでは非効率的でした。MIDP 3.0 では、このオーバーヘッドを解消するために「レコードタグ」が導入されてました。各レコードに整数値のタグを割り当てることで、効率的に列挙を行うことができます。 デバイス要求 デバイスのハードウェアおよびソフトウェアに対する要件は以下の通りです。
仕様策定までのスケジュール JSR 271 は JCP パージョン 2.6 のプロセスに基づいて進められています。これまで、および今後のスケジュールは以下の通りです。
|