AU 向け Javaプログラムを作っている。
前の日記では機能の低さを嘆いていたが、それなりにプログラムは形になってきた。
しかし、やはり機能が低いとプログラム量が多くなる。
以前作った i-mode 向けプログラムは 10K の制限内で作ったが、AU は 50K なので機能追加も多く、プログラム量が多くなる。
プログラムが多くなり、把握しにくくなるとバグの元なので、分割コンパイルを行いたいのだが、Java には分割コンパイルという概念はない。
というか、C 言語と違ってオブジェクト指向言語なので、分割は「オブジェクト」単位で自然に行われる。
オブジェクト指向というのは、一度完成した「プログラム」を後からいろいろ使いまわせるような仕組みをいう。
使いまわすためには、プログラムの中身はわからなくても、外部への窓口がしっかりしていれば良い。
というわけで、Java はやたらと「窓口」を作る。勝手に作る。作りすぎてメモリを食う。
しかし、携帯電話ではメモリが少ない。対処方法としては、オブジェクトを出来るだけ少なくして、外への窓口も出来るだけ作らないようにすればよい。
しかしこれは本来のオブジェクト指向が目指している方向と正反対だ。
無理なつくりをするので、プログラムは非常に読みにくい、厄介なものとなる。
対症療法としては、Obfuscatorというのがある。
「窓口」というのは、つまり中を覗くためのきっかけにもなりやすい。
Java のプログラムは中身を見られやすいのだ。仕事で使うには、これは困る。
そこで、中身を見えにくいように窓口を「変な形」にするツールが考え出された。
Obfuscatorとは「混乱させるもの」という意味だ。
たとえば、「OpenWindow」という名前がついた窓口があったとしよう。
名前からも、窓口とわかりやすい。Obfuscatorはこれを「a」というような、無味乾燥な名前に変えてしまう。
これは副作用として文字数を減らし、メモリの節約にもつながる。
実際のところ、フリーのObfuscatorはRetroGuardくらいしかないのでそれを使うことになる。
KDDI は、Java プログラム作成を促すためにKJX 作成キットを配布している。
(KJX というのは、KDDI の Java 配布形式の名称だ。EZPlus のプログラムのことと思って良い)
この中には、ややこしい Java プログラムのコンパイルを補佐する GUI ツールも含まれている。
…が、これが非常に性能が低い。
i-mode での開発をしていた時には、フリーウェアのiアプリ開発Toolを使用していた。
これは、ボタン一発でコンパイルを行って、RetroGuard までかけてくれた。
しかし、KJX 作成キットではそのようなことは出来ない。
いや、それどころか、KJX 作成キットでは、実は配布形式の KJX を作ることが出来ないのだ。
KJX は配布時に 2byte の CRC チェックを付加する必要があるのだが、KJX 作成キットはその「あたりまえのこと」をやってくれない。
MIDP Builder2というものがあるのを発見した。
このソフトは、KJX 作成キットでは出来ないことをほぼ解消している。
買おうかどうしようか…と迷っていたところ、自分が一番欲しいと思っている機能が欠けていることに気づく。
ここまで来たら、仕方がないので自分でコンパイル環境を組むことにした。
最初はバッチファイルで書こうとしていたが、無理っぽいので windows に perl を導入し、perl で書いた。
まずは KJX 作成ツールが行うのと同じことが出来るのを確認。
その後、RetroGuard でプログラムを縮小する処理を追加。
正常動作を確認。
さて、ここまで来て、再び最初の問題。
Obfuscator は解決ではなく、むしろ問題を悪化させる。
そもそも、問題は「プログラムのメモリ量」ではなく「ソースの量」が多いことだ。
読みにくいので分割したい。MIDP Builder2 にかけていたもの、というのもこれだ。
C 言語なら分割できる…というのは、２つの意味があるのだがここでは「プリプロセッサ」の仕組みを導入してみよう。
プリプロセッサを使うと、ファイルの一部として別のファイルを呼び出すことが出来る。
#include というやつだ。C言語を知っている人なら見たことあるだろう。
これは、厳密に言えば分割コンパイルではないのだが、ソースを分割できる。
ソースが分割できれば、プログラムの見通しというのはある程度良くなる。
その「ある程度」がプログラマにとっては非常に重要なのだ。
で、フリーで使えそうなプリプロセッサを探す。
pamulow preprocessorというのを発見。
#include もつかえる、と書いてあったので期待したのだが、実はこの include 文は、非常に限られた用法しか出来ないと判明。
ソースの分割には使えないのだ。これでは意味がない。
そもそもプリプロセッサというのは C言語のアイディアだし、C言語のプリプロセッサを流用するのも悪くない。
そう思って、MS-DOS 時代にはずいぶんとお世話になったLSI-C 試食版をダウンロード。
しかし、これも実は使えないことが判明。
機能的には十分なのだが、なにぶん MS-DOS 時代のものなので、ロングファイル名に未対応だったのだ。残念。
他にないかと探してみると、Borland C++の無料版が見つかった。
Borland C というのもずいぶん懐かしい。大学時代、授業では TurboPascal を使っていた。後に TurboC もつくられ、さらに Borland C/C++ となるわけだが、当時としては一番使いやすい環境だった。
そんなノスタルジーに浸りながらダウンロード。
というか、ファイルが巨大でダウンロード中に思い出に浸っていたというか。
ただプリプロセッサが欲しいだけで、８メガ以上のファイルをダウンロードするのもどうかと思う。
しかし、Borland C++ のプリプロセッサは期待以上の動きをした。
最初からいっしょに設計されたCなどでは問題ないのだが、プリプロセッサを通すと行番号がわからなくなってしまうのが難点だ。
しかし、Borland C++ のプリプロセッサは、「すべての行の先頭に、コメント形式で元のファイルと行数を入れる」という対処方法でこの問題をクリアしていた。すばらしい。
そんなわけで、理想的な開発環境は整った。
しかし、使いもしない C++ が、50M のハードディスクを食っている。
あまり人に勧められる環境構築ではない (^^;;
同じテーマの日記(最近の一覧)
関連ページ
【追悼】森公一郎さん （LSI-C の作者）【日記 15/01/20】
Synchronized, wait & notify【日記 02/10/31】
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |