フォントのスケルトン化に挑戦中。
なにげなくソートをしようとしたら、JDK 1.2以降にしかAPIがない。なるほどMSが独自パッケージを入れるわけだと納得したが、納得しても問題は解決しない。
（この世には、記憶すべきでないことがいくつかある。ソートのアルゴリズムもその一つだ。
ソートを不必要にコーディングすることによって生産されたバグの数はおそらく現在までに10万以上、それによって生じた損失の総額は5000万ドルを下るまい）
というわけで、かねて懸案の、jview.exeの部分的なJDK
1.3化に挑戦した。全面的な1.3化は不可能だろうが、java.util.*だけでも1.3化できればぐっと楽になる。
結論：成功した。手順を以下に示す。
1. MS SDK for Java 4.0（こんなものが世の中にはある。MSからダウンロードのこと）に含まれる、ClassD.exeを実行する。再起動するかと訊かれたら、Nと答える。
2. %SystemRoot%\java\classes.zipの中にあるjava\utilを、JDKのrt.jarの中にあるjava\utilに差し替える。
3. 再起動。
依存性は一切追っていないので、いつなにが起こるかわからないが、とりあえず私の使うものは使える。
今日までの成果は、
量：直線成分
曲線成分
避：直線成分
曲線成分
鬱：直線成分
曲線成分
25%くらいできたような気がする。
フォントのスケルトン化に挑戦中。今日までの成果は、
量：直線成分
鬱：直線成分
曲線成分はまだだ。
どうやらものになりそうな気がしてきた。しかし先は長い。
Visual J++と、NTT DoCoMoの公式DoJaエミュレータを連携させることに成功した。
プロジェクトのプロパティのカスタム：「ビルド後に実行されるコマンド」に、事前検証やjarに固めるコマンドをずらずらと書けばいい。起動はカスタムで云々。
しかしpreverifyが遅くて頭にくる。
javac、jikes、jvcの3つのJavaコンパイラを、uidemoのjarファイルの容量で比較してみたところ、javac
< jikes < jvcとなった。javacとそれ以外とでは1割近く違い、jikesとjvcの差はわずかだった。
IBMが磨き上げたjikesに負けるのは仕方ないとして、たいしたことはないと評判のjavacが一番小さいというのは面白い。KVM用のなにかがあるのかもしれない。
今度はKopiで試してみたいが、bootclasspathオプションがあったかどうか。
J2MEではデバッガは使えないので、残る問題は、J2MEのシステムクラスファイルをVisual
J++のjvc.exeが読み込めるか、である。
ネイティブコンパイラの理屈からいえば読み込めるはずだと思い、まずはJDK
1.3のrt.jarで試してみたところ、見事に読める。
オブジェクトブラウザから「現在のパッケージ/ライブラリを選択」ボタンを押し、「Javaのインストール済みパッケージ」のチェックを外す。プロジェクトのプロパティから「固有のパス」にrt.jarへのパスを加える。以上である。入力支援も完璧に働く。
これならCLDCでもいけるだろう。また一歩野望に近づいた。
UML Pressの創刊号を読んだ。
私は、人のやらないことか、誰でもやっていることか、どちらかしかやらないことにしている。「流行の最先端」などというのはリスクばかり大きくて、しかも本当の最先端などではない。
よって、デザインパターンもUMLもXPも無視していたが、どうもかなり普及したようなので、手始めにUML
Pressを読んでみたのだった。
デザインパターン：概念の直交性が悪くて落ち着かない。
UML：実装と設計を分離するのは大変ですね。
XP：14カ条が全部実行できたら、いい結果が出て当たり前。
Visual J++とJDKを統合しようとして色々調べたが、どうやらデバッガがネックになっていて、一筋縄ではいかないことがわかった。
どうせJ2MEではデバッガが使えないので、デバッガは無視することに決めた。
フォントのスケルトン化に挑戦中。今日までの成果は、
あ：直線 曲線
量：直線 曲線
鬱：直線 曲線
バグだらけなのはご愛嬌として……このアルゴリズムは根本的にダメかもしれない。うーむ。
昨日の続き。
調べてみてわかった。JDK 1.1.xまでとJDK 1.2.x以降では、BufferedInputStream.read(...)の挙動が違う。MSの実装は、JDK
1.1.x準拠だからあれで正しい。
夢にも思わなかった――こんなに重要なAPIの挙動を、たいしたメリットもないのに、こんなにドラスティックに変えるとは。
古い挙動の評判が悪かったとしても、同じメソッド名にする理由が、まったくわからない。readAuto(...)というメソッドでも新設すればいいではないか。いったい、なぜAPIの挙動を変えたのか。あきれて物が言えないとはこのことだ。
プラットフォームの仕様変更に関する$unのポリシーは、いったいどうなっているのか。Javaはもう駄目だとは思っていたが、駄目どころか狂っているらしい。
Visual J++ 6.0を手に入れた。
アンチ$unな気分がたまらなく素晴らしい。また、噂にきくとおり、実によくできたIDEで、重く不可解なForteとは雲泥の差がある。
が、さすがにアンチ$unだけあって、たとえばBufferedInputStreamの動作は、どう考えてもMSのほうがおかしい。$unのドキュメントによれば、バッファの最後まで読んだら自動的に補充されることになっているが、MSの実装ではバッファが尽きるところまでしか読めない。これが世に名高いMS商法か。うーむ。
…と思ったら、翌日へ続く。
