解説


モバイルJava普及で急浮上の「intent」とは?



鈴木都木丸
グルージェント
2001/4/14


 intent「intent Java Technology Edition(intentJTE)」は、昨年末の英Taoアスキージャストシステム日本語化に向けた提携の発表以来にわかに注目を集めていた。そして先日、シャープのZaurusがJava実行環境に採用したことでふたたび注目を集めている。

開発者向けにZaurusでのJavaを使ったアプリケーション開発の情報が提供されている(http://more.sbc.co.jp/pjzaurus/pjzaurus.asp

 intentは英Taoがすでにもっていた仮想OS「Elate」をベースに、1996年よりアスキーと共同開発を進めてきたJava実行環境である。

アスキーのWebサイトにはintentについて詳しく紹介したページが用意されている(http://www.ascii.co.jp/tao/

 Javaは確かに「Write Once Run Anywhere」を実現しているが、その実行環境がPCやワークステーションなどのように必要十分なパワーを所有しているとは限らないだろう。サーバ・サイドではすでに主流となりつつあるJavaだが、非力なプラットフォームでは、まだC/C++やアセンブラといったネイティブコードに歩を譲っているというのが実情である。

 Javaの実行速度はHotSpotテクノロジによってかなり改善されたたとはいえ、非力な環境ではJavaバイトコードを実行することは現実的な選択肢にはなり得ていない。では、非力なプラットホームではJavaテクノロジは有効ではないのだろうか。Java開発者がジレンマとして持っていたこの問題を解決するソリューションが実はintentなのだ。

生い立ちは独自のマルチプラットフォーム環境

 英Taoは、もともと8ビットパソコンのゲーム開発に強いソフトハウスだった。しかし異なるプラットフォーム毎にコードを書き直していたのでは開発の生産性が低下してしまう。そこで、同社は仮想プロセッサというアイデアを仮想OS「Elate」に実現した。

 Elate用のコンパイラはソースコードをElateのVP(仮想プロセッサ)コードに変換する。つまり、開発者はプラットフォームの違いを意識することなく、Elateをターゲットに開発を行えばよいのだ。ElateはVPコードがメモリ上にロードされると同時に、ターゲットのプラットフォームにネイティブなコードに変換して実行する。当然ながらインタープリタよりも高速にプログラムは実行される。しかもネイティブコードへの変換処理は最適化されているため、ネイティブプログラムを始めから実行する場合に比べて遜色ないスピードで実行される。

英Taoのintent紹介ページ。最新の情報はここから入手できる(http://tao-group.com/2/tao/index.html

 WindowsやLinuxなど、さまざまなプラットフォームに向けてElateを用意すれば、一度書いたコードがさまざまなプラットフォームで動作する。英Taoは、サンのJava誕生以前に「Write Once Run Anywhere」の思想をもち、Elateというマルチプラットフォームのプログラム実行環境を開発していたことになる。

intentはJava言語でElateをターゲットに開発するための環境

 intentはこのElateとJava実行環境を組み合わせた製品である。よってその生い立ちや性格は従来のJavaVMとは異なるものである。JavaVM以外でバイトコードが動作するということに不安を持つかもしれないが、intentのJavaエンジンはサンにJavaVMとして認定されており、問題が発生することは事実上ないと考えてよいだろう。

 intentはJavaバイトコードをElateで動作するVPコードに変換して実行する。つまりElateが実行するのは直接的にはJavaバイトコードではなく、変換されたVPコードなのである。言い換えれば「intentはElateをターゲットにした開発をJava言語を用いて行えるようにした環境」ということなのだ。ちなみにElateのC++コンパイラが出力するコードもVPコードであるため、Elate上でのC++コードとJavaバイトコードにパフォーマンス上の優劣はほとんどないといえる。

 パフォーマンスのほかに、JavaVMに対するintentのアドバンテージとして、非常に少ないメモリ上で実行できるというものがある。これはintent独自のダイナミック・バインディングが実現しているものである。Elateは多数のツールと呼ばれるモジュール群で構成されており、これは実行時に動的にメモリにロードされ、必要がなくなればアンロードされる。Elateは、このダイナミックバインディングにより、JavaVMのように巨大なメモリ空間を必要とせず、高いパフォーマンスを実現している。

intentが抱える課題

 intentのJava仕様は古い。PersonalJavaを採用しているのは、J2MEよりも高い機能を追及した結果というよりも、開発のスピードの問題といえる。そのほかにも、日本語対応やマニュアルの不備など、現時点では課題も多い。以下に、列挙してみよう。

■Java2への対応
 現時点ではJDK1.1.6互換のPersonalJava 1.1.3に対応している。これはJava2プラットホームには対応していないことを意味している。JFC/Swingをサポートしないのは時代遅れであり、最新のJDKサポートがされないようではintentの魅力も半減する。この問題は時間が解決してくれることを期待したい。

■日本語対応
 現時点ではIMEが存在しないため、日本語入力はサポートされていない。ただ、現在ジャストシステム、アスキーが共同でintent対応のATOKの開発を進めていくため、近いうちにこの問題は解決されるだろう。試していないが、Zaurus版のintentでは入力がサポートされていると十分予測できる。

■Elate API のJavaクラス提供
 Elateには多数の独自のAPIが存在しているが、これを直接利用するにはC++やアセンブラを利用するしかない。intentがJavaをサポートするというのであれば、各種APIを内包したJavaクラス(さらにはBeans)を提供してほしいところである。intent内部にはJavaパッケージらしきディレクトリが存在しているため、実はすでに存在しているのかもしれないのだが、筆者が試したところ、intent上でjavacは動作せず、jarファイルも提供されていないようだ。さらにはこの辺りの情報がほとんど存在していないことはJava開発者の興味を失わせる結果となるだろう。

■ハードウェアの進化
 現在、パフォーマンス的にintentがかろうじて現実的に利用できるのはPocketPCのカラー版のみであろう。そういう意味では「次世代の技術」であるともいえる。PCのように急速な進歩は期待できないだろうが、1年もすれば現実的なパフォーマンスが出るPDAが出現してくることは十分期待できる。

 もう1点、意外に重要な要素として、マニュアルの存在がある。Java開発者のために用意されている現在のマニュアルはElateコンソール上でJavaを動作させる記述しか存在していない。そのため、実行イメージをバイナリにして直接Elateで動作させたりするには、Elateのマニュアルを読むしかないのだ。ところが、現実にJava開発者の多くがElateに対して必要としているのはJavaVMとしての機能であって、OS機能ではない。この真実はElateの学習に対する意欲を微妙に減退させる効果がある。このため開発者をC/C++などのネイティブコンパイラに奪われる心配がある。TAOとしては本意ではないのかもしれないが、ElateをJavaエンジンとしてだけ利用するためのマニュアルを用意してもらえると、この辺りの危惧も杞憂に終わることだろう。

 以上のように、現時点としてのintentは「成長途上の大器」という感じである。しかし、上の問題が解決できれば情報端末OSとしてかなり有力なソリューションであるといえる。

 なぜならば、生産性やメモリ管理、学習の容易さなどの点でJavaはC++よりも有利であり、今後爆発的に増加するであろうJavaプログラマがそのまま開発者人口につながることは独自のOSを提供する情報端末と比べ、技術者人口を確保できるからである。

 筆者としては、intentがサーバ分野を含め、全てを包括するソリューションになることはないと感じている反面、現時点の注目度からいっても情報端末の分野では大きなソリューションウェーブになるのではないかと感じている。



Java Agile フォーラム 新着記事
@ITメールマガジン 新着情報やスタッフのコラムがメールで届きます(無料)

注目のテーマ

Java Agile 記事ランキング

本日 月間