そして現在進行中なのが、
auの携帯電話向けのBREW版ドダイ・モバイルの開発です。
iアプリ・S!アプリがなんだかんだで
Javaという同じ言語をベースにしていたのに対し、
BREWはC言語もしくはC++言語を使ってプログラムを進めていくことになります。
この、C系の言語を使う、というのが
ドダイ・モバイルのプロジェクト開始以来ですっかり
Javaの世界に慣れてしまった身にはいささか辛いものがありました。
BREWはC系の言語を使うところからもわかるように、
言うなれば「昔ながらの世界」という感触が強いです。
とにかく「直接触れる・触っている」と感じます。
JavaではVM層が存在するため、
その上で動くプログラムが多少悪さをしたところで、
ベースシステム（携帯電話全体）にまで大きな影響が及ぶことはまれでした。
しかし、BREW用のプログラムでは、
プロセスという単位での保護すらありません。
BREW用のプログラム（アプレット）は、
実際には携帯電話からDLLとして呼び出されることにより動作します。
……という動作モデルを正しく想像できた方なら、
その危険性にも気付かれることでしょう。
そう、BREWのプログラムはベースシステムに影響を与えます。
メモリリークすればそれはシステム全体のメモリリークであり、
完全に電源を落とすまで悪影響は残り続けることになるのです。
そういった弊害があるために、au用にBREWのプログラムを作っても、
KDDIによる審査・検証を経なければ公開することができません。
しかも、APIやその他開発資料にアクセスするための障壁も
高くなっているため、iアプリやS!アプリに比べて圧倒的に情報が少ないのです。
5年前の時点ですでに枯れていたやり方をベースに、
当時の機器のハードウェアの限界の中で最大性能を引き出すことを目指した。
BREWというのは、そういうプラットフォームです。
対してJavaは、5年前に携帯電話に載せるのには正直無理がありました。
しかし時代は進み、今や携帯電話で採用されるような
CPUでもJavaは楽々と動作するようになりました。
既に携帯電話用のアプリ開発では、
Javaの方にアドバンテージがあると思います。
対してBREWは、
現代的なプログラミングの常識からすればやはり辛い環境です。
しかし数少ない救いは、出来上がる実行形式ファイルの小ささと、
関数ポインタの存在でしょう。
特に関数ポインタの存在は大きいです。
iアプリやS!アプリでは、やはりJarサイズの制限から
あまり野放図にクラスを作れないという制約が課されます。
しかし、仮にC++でなくCを使ったとしても、
関数ポインタがあればよっぽどオブジェクト指向らしい、
ずいぶん綺麗なコードを実現できます。
やはり小さなサイズに多機能を詰め込むのなら、
そしてそういった制約のある中でコードを綺麗に保ちたいなら、
関数ポインタ的な機構は必要だなあ、と痛感しています。
とはいえこの状況も、今後のCLDCの発展で
リフレクション回りが充実すれば逆転するのでしょう。
と、あまりまとまっていませんが、
ここらで今回は筆を置きたいと思います。
ドダイ・モバイルにもう少し進展を迎えたあたりで、
またなにか書く機会があるかもしれません。
