JDK1.3 で Swing 1.1 のサンプルである SwingSet を動かすと、Internal Frame のサンプルがうまく動かず不思議に思っていたのだが、JDK のドキュメントを読んでいてようやくその原因が分かった。1.3 で内部フレームはデフォルトで表示されないように変更されたためであった。w.setVisible(true); という行を２ヶ所書き加えたら正常に動くようになった。
ソフトウェアクーラーとして今まで Rain を使っていたのだが、FIVA では Rain の効果はほとんど見られなかった。FIVA では、CPU の温度が一定以上になると、CPU 速度が 75% あるいは 50% になって発熱を抑えるようになっている。困ったことに、電源を入れたまましばらく置いておくだけで CPU の温度が上がり CPU 速度も 50% になってしまうのだが、50% では動作が実にのろくていらいらする。しかも Rain を使ってもこの状況に変化はなかったのである。今回、代わりに PowerCut を使ってみた。Rain とは違い、明らかに効果が出ている。しばらく置いておいても CPU の温度は一定以上には上がらず、CPU 速度は 100% のままである。しかも一定時間パソコンを操作しないと、自動的に HDD が停止するようになっている。FIVA の HDD は妙にうるさいのでこの機能は気に入った。次に Ls178 でも PowerCut を動かしてみた。HDD 停止機能があまりうまく機能していないような気がする。冷却効果はやはり Rain よりも大きいように感じた。Rain とは違って DOS アプリに対しても冷却効果がある点が強力である。
M$ JVM で Swing を使っているプログラムを実行するとき、毎回コマンドラインで swingall.jar のパスを指定していたのだが面倒になってきた。調べてみたところ M$ JVM の CLASSPATH は、HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Java VM\Classpath で設定されていることが分かった。この値を書き換えて swingall.jar のパスを書き加えてやったところ、無事に Swing が使えるようになった。もしかしてこれで IE 上でも Swing を使ったアプレットが動くようになったのだろうか。
ということで IE で Swing を使ったアプレットを動かしてみたところ、どうやら正常に動いているようである。ついでだから NC4.75 でも同様のことができるか試してみた。\Program Files\Netscape\Communicator\Program\java\classes\ に swingall.jar をコピーしたところ、とりあえず Swing を使ったアプレットが動くようになったのだが・・・、アプレットの初回の起動に異常に時間が掛かる。はっきり言って使い物にならない。まあ、ブラウザ上で Swing が動くということが分かっただけで良しとしよう。
IBM 製 JDK 1.3.0 をダウンロードしてきた。あまり使う予定もないが Linux 版も一緒に落としてきた。早速インストールしてみた。IBM の JVM を標準の JVM とするようにしたのだが、.jar の関連付けが変になってしまった。サンプルの SwingSet を実行してみたところ微妙に動作が不安定な気がしたので、\windows\ の java.exe, javaw.exe を imbjava.exe, ibmjavaw.exe にリネームして、代わりに元の Sun の java.exe, javaw.exe をコピーして、関連付けも元に戻した。速度を測定してみたが、java.io.File の速度は Sun のものとほとんど同じで、FastFile はわずかに速かった。起動に掛かる時間は IBM の方が少し短いが、M$ ほど速くはない。全体的に Sun のよりは速いが期待したほどではないというのが正直な感想である。
M$ 製の JVM(JavaVM) の速度を測定してみた。以前と同じように \windows\system のファイル一覧の取得にかかる時間を計った。M$ 製 JVM（JDK1.1相当）: 約7.8s、Sun 製 JVM（JDK1.3）: 約9.2s という結果になった。やはり M$ の方が速い。
M$ JVM で Swing を使ったプログラムも実行してみた。ダイアログボックスを表示させると、初回の表示は少しもたつく。しかし全体的な速度は JDK1.3 よりも速いように感じた。JDK1.3 では HotSpot で速度が大幅に改善されたといわれてたはずだが・・・。ただ M$ JVM で Swing を使うとフォーカス関連で動作が少しおかしいところがある。特にメインウィンドウでキー入力を受け付けないのは痛い。requestFocus() を使えばとりあえずはキー入力ができるようにはなるのだが、メニューにフォーカスが移ると、その後でメインウィンドウにフォーカスが戻ってこない。これではファイラーが作れない。
しかし、Sun の JVM の遅さは何とかならないものだろうか。そういえば以前 IBM が Linux 用の高速な JVM を出していたはず。Windows 用の JVM は公開されているのだろうか？ 検索してみると IBM 製の JDK 1.3.0 が見つかった。（Windows 版 | Linux 版） ダウンロードするのに登録が必要なのは少し面倒だ。そういえば以前にもダウンロードしようと思ったことがあったのだが、登録が面倒でダウンロードをやめたのだった。登録が終わってダウンロードしようかと思ったら・・・、サイズがやたらでかい。JDK が 41MB、JRE が 18MB もある。明日大学でダウンロードしてくるとするか。（IBM のサイトは table のネストが深いせいで、NC4.75 を使っていると表示に異常に時間が掛かる。何とかならんのか？）
Mozilla 0.9.2 をダウンロードしてきた。Windows の起動時に Mozilla の一部を常駐させて、Mozilla の起動を速くできるようになっていた。実際に試してみたところ、Windows の起動は少し遅くなったが、Mozilla の起動は確かに速くなった。起動だけでなく、本体の動作速度ももっと速くなってくれると良いのだが。久しぶりに Messenger を使ってみた。スペースバーの連打で未読メールを読み進めることができるようになっていた。動作速度は遅いが。
java.io.File の list() と listFiles() の速度を調べてみた。ファイル数 10,000 のディレクトリで list() : 約3.2s、listFiles() : 約4.1s であった。list() で得たファイル名を元に File オブジェクトを生成した場合は 約3.6s であった。listFiles() 単体よりも、list() + new File() の方が速いというのは意外であった。ここで掛かっている時間のほとんどはおそらくオブジェクトの生成に使われているのだろう。この実験結果と比較すると、FastFile.listFiles() で 約3.4s というのは妥当な値かもしれない。これ以上の高速化はおそらく無理だろう。Win32API を使ってのファイル一覧の取得には 0.5s 程度しか掛かっていないので、本当はもっと高速化したいところではあるのだが。
プログラムの実行速度を測定するためのプログラムをちょっと書いてみたが１秒単位でしか時間が取得できなかった。やはり PC-98 だからか。ふと思い出して hrtimer.sys, vhrtd.vxd をインストールしたところ、10ms 単位で時間が取得できるようになった。
おととい書いた FastFile のチューニングを行った。ファイル数 10,000 のディレクトリでファイル一覧を取得するのに掛かる時間が 3.4秒程度まで短縮された。1秒未満まで短縮したいものだが。
jFD のサイトの掲示板にも以前書いたが、Java ではファイルの各種属性（サイズ、日時も含む）を得るルーチンの速度はかなり遅い。jFD でディレクトリを開くのに時間が掛かるのはこれらが関係しているようだが、JF でもソートをするようにしたら jFD 並に遅くなる可能性がある。そこで、これの対策を調べてみることにした。
Windows では、これらのルーチンは java.dll が実際の処理を行っているようである。java.dll をちょっと調べてみたところ、ファイルの各種属性を取得するたびに stat() を呼び出しているようである。Win32API では、FindFirstFile(), FindNextFile() を使ってディレクトリ内のファイル一覧を取得する際に、同時にファイルの各種属性も取得できるわけだが、Java でファイルの一覧と各ファイルの属性を取得する際には、まずファイルの一覧を取得して、その後でファイルの属性を取得する必要がある。つまり Win32API を直接呼び出せば FindFirstFile() の呼び出しは１回で済むのだが、Java を使うと複数回呼び出されることになるのである。（stat() は、内部で FindFirstFile() を呼び出している。） ファイラーで、ファイルを各種属性に従ってソートする場合、これは明らかな無駄である。
この無駄を省くために、JNI を利用してファイルの一覧を取得する際に同時にファイルの属性も取得するようにしたクラス(FastFile)を作ってみた。ファイルの一覧を取得し、各ファイルの日付を調べるテストプログラムを書いて、java.io.File との速度を比較してみた。まず、\windows\system（ファイル数 1,181）では、FastFile が 1〜2秒、java.io.File が 9〜10秒。次にファイル数が 10,000 のディレクトリを作って同じように時間を調べると、FastFile が 7〜8秒、java.io.File が 約580秒という結果になった。JF では、ソートを全くしないか、純粋にファイル名だけでソートする場合は、java.io.File を使い、属性に応じてソートする場合に、FastFile を使うのが良さそうである。
JF の設計を１からやり直そうとしているのだが、相変わらず全然進んでいない。こういう細かいことだけは進むのだが。
12倍速まで対応しているはずなのに、LCW-R6424DV との相性が悪いのか、2倍速以下でしか焼けないという困った CD-R メディアがある。この前買った CDW-U4424 で焼いてみたところ、無事に 4倍速で焼くことができた。
アクセストレードというところから、広告を掲載させて欲しいというメールが届いた。１日のアクセスが高々数十件のこんなサイトに広告を載せたところで・・・。載せるべきかどうか迷っている。小遣いの足しにもならないような気がするが。
また変なプログラムを作ってしまった。要は、以前書いた fjavac.bat（2000/05/24 参照）を実行ファイル化しただけである。よく考えると .ini ファイルやレジストリを扱うプログラムを書いたのはこれが初めてかもしれない。