JavaAppletはダサい - Florian’s NewestDiary

もう、今となってはブラウザ内でJavaAppletが動くことをありがたがる風潮なんかないわけで、RIAを作るのであれば起動の速いFlexやSilverlightを使った方がずっといろんな意味で便利。
と、いうわけで、JavaAppletのダサい所を。

起動が遅いのがダサい

JRE1.6.10から劇的に早くなりました。が、それでもやっぱりVMの起動に時間がかかります。特に初回。どれくらい遅いかというと、「Windows7/Vistaでプロセスから応答がなくなるのが一定時間たつとブラウザウィンドウが白くなる」ぐらい遅い。
2回目以降はVM インスタンスをキャッシュしているらしいのですが(これは、別の挙動から判る)、白くなっちゃだめだろう、白くなっちゃ。「プロセスは応答していません」とダイアログが出ないだけまだましだけど。

メディアハンドリングがダサい

Javaは伝統的にメディアハンドリングが苦手です。ムービーとか、音声とか。なので、JavaMediaFraeworkという物がJNI経由で提供されています。後付でインストールが必要です。
じゃあ、JNIを使わないと「ムービーはだめ」「音声は無圧縮Wavかau」「なぜかMIDIはソフトウェア音源をサポート」という偏りっぷり。いまどき、auなんか、フォーマット自体を知ってる人いないって。

~~終了を検知できない~~出来ました。Applet.destroy()です

ページを遷移したとか、リロードしたとかでAppletの終了を検知して終了処理をさせたいのですが、そもそも終了が検知できません。finalize()来るかなーと期待してたんだけど、それすらも来ない。おもむろにスレッド落とされます。
にもかかわらず、ブラウザのプラグインはJavaVMのインスタンスをキャッシングしてプーリングしているので、非同期で勝手に動いているAudioClipは止まってくれません。

グラフィックの非同期ロードが遅い

特にToolkit.createImage()なんかを使うと顕著に遅いです。元々このメソッドは非同期ロードを行うことを前提にしているのですが(なので、ロードが終わったらコンポーネントに再描画を促すインターフェースがある)、これがクラスファイルと同じjarファイルの中に入っているイメージであってもロードに時間がかかります。
メモリからの展開なんだから、それぐらい一瞬でやれよ(ちなみに、ImageProducer経由で同期ロードする方法もあります。遅いけど)。

クライアントサイトストレージが当てにならない

HTML5やGoogle Gearsが一般的になる遙か前から、クライアントサイトストレージの重要性をJavaは良く理解していました。が、先の「終了を検知できない」と「ページ遷移時、スレッドの途中でも問答無用で落とされる」の所為で、書き込んでいる最中に落ちることがあります。
なので、なんか微妙に当てになりません。

メモリが少ない

ディフォルトで確保されているヒープメモリは64Mが最大です。この値は、Java プラグインの設定をクライアント側で変えない限り変更できません。いまどき、64Mのヒープで何をやれと。ImageやAudioClipを作ると大幅にメモリ食うし。

ハードウェアアクセラレーションが効かない

実はJavaのJREの強みの一つとして「描画に勝手にハードウェアアクセラレーション使ってくれる」という物があるのですが、なぜか(SunはWindows側のバグだと言い張る)Appletはハードウェアアクセラレーションが効きません。なので、デスクトップで十分なパフォーマンスが出ていたはずのソフトが妙に重くなることがあります。

いくつか(最大メモリ問題と、追加フレームワーク問題)はjnlpをJava Appletで採用することで微妙に解決します。後発のテクノロジーであるJava Web Startではこの辺おおむね解決されていますので、その方法論をバックポートしてるんでしょうね。
でも、根本的なダサさはあんまり解決されていないのでした。
Java Web Startつかえって事だな、うん。

どうでもいいけど、ATOKは「ダサい」を形容詞と見なしてないらしい。死語の世界(^^;)。